Meetings (Beta) exceeds four-hour limit and remains stuck after HTTP 413 finalization failures

Finding: In one reported session on macOS ChatGPT/Codex 26.1007.21159 with Meetings plugin 0.8.77 and native companion 0.5.0, a Meetings (Beta) recording that exceeded four hours did not stop automatically. After the user stopped it at about 4h57m of captured audio, upload finalization repeatedly failed with HTTP 413, the UI stayed on Taking notes, and the server still reported the meeting as recording (https://github.com/openai/codex/issues/52794). Reported evidence: The reporter lists capture_phase=stopped, delivery_phase=finalizing, a recovery failure code ending http:413, failure_category=http-rejected, and stream_end_called_at=null. They say 76 HTTP 413 finalization failures had been logged by 06:58 UTC on October 10, and that retries accepted zero frames (https://github.com/openai/codex/issues/52794). The issue cites help documentation saying sessions stop automatically at four hours, which conflicts with the behavior seen here (https://github.com/openai/codex/issues/52794). Reprocessing: A reprocessing request returned HTTP 409. The client showed a generic invalid-response message. A second guarded attempt captured the server text: Recording end could not be confirmed. Stop the recording before reprocessing. So the 409 appears to follow from the server never confirming the recording end, not from a separate fault. Local capture was already stopped, the companion was idle, and its targeted upload retry returned unsupported (https://github.com/openai/codex/issues/52794). Unconfirmed: The cause of the 413 is not established. The reporter says a request limit is possible, but the limit and its link to duration are unconfirmed. No maintainer response, fix commit, or release is in the supplied sources. Mitigation status: The reporter preserved the audio journal and recovered the transcript tail and system audio, then saved recovered notes in the existing Page. This made the notes usable but did not repair the upload or processing state (https://github.com/openai/codex/issues/52794). It is a user-specific recovery, not a verified fix. Limitations: This is a single external report from one session, not reproduced in a second long recording. KFA did not reproduce it. Only the issue body was supplied, so comments may be missing. Diagnosis is limited to treating the 409 as a symptom of the unconfirmed recording end, with HTTP 413 finalization as the unresolved upstream failure.