Goal resume after 5-hour usage limit can get stuck in approval prompts despite Full Access; iOS lacks goal pause/resume controls

Summary

Persistent goals can become effectively stuck after the 5-hour usage/token window is exhausted and the next continuation/compaction happens. On the next day, resuming those goal threads from desktop shows the workspace as Full Access, but the resumed goal prompts for approval on nearly every step. The user cannot recover the stuck goal from iOS because the mobile UI does not expose the goal pause/resume controls.

What happened

Observed flow:

1. Start one or more long-running /goal tasks.
2. Let them run until the 5-hour usage/token limit is reached.
3. After the limit is reached, the first compaction/continuation occurs.
4. The goal gets stuck or cannot continue cleanly.
5. The following day, after the usage window resets, resume the affected goal threads from desktop.
6. The UI still indicates Full Access.
7. Despite Full Access, the resumed goal repeatedly enters awaiting approval / approval-required states for ordinary steps.
8. On iOS/mobile, there is no visible goal pause/resume control, so the user cannot resume or recover those goal threads from the phone.

Expected behavior

• A persistent goal that was started under Full Access should resume under the same effective permission mode after a rate-limit pause, compaction, restart, or next-day continuation.
• If Codex cannot preserve the original permission mode, it should surface that explicitly and offer a repair path instead of showing Full Access while prompting for every action.
• iOS/mobile should expose the same essential goal lifecycle controls, at minimum pause/resume, so a user can recover or continue goals without needing desktop access.

Actual behavior

• Goal threads that appear to be in Full Access require approval repeatedly after resuming.
• The approval prompts make the goal continuation unusable for unattended or long-running work.
• The mobile UI does not provide pause/resume controls for goals, preventing recovery from iOS.

Impact

This breaks the main value of long-running goals: the user cannot leave a goal running across the 5-hour window and then reliably continue it later. It also creates a confusing state where the app says Full Access but behaves as if approvals are required for every step.

Related issues

This seems related to permission/profile drift and Full Access mismatch reports, but this issue adds the goal-specific 5-hour-limit + compaction + next-day-resume path and the iOS control gap:

• #25590
• #28296
• #21839
• #27134

Requested fix

• Persist and restore the effective sandbox/approval profile for active goals across usage-limit interruptions, compaction, app restart, and next-day resume.
• Reconcile visible Full Access state with the actual per-thread/per-goal approval state before continuing a goal.
• Add a visible repair path when a thread says Full Access but is persisted as approval-required.
• Add goal pause/resume controls to the iOS/mobile UI, or provide an equivalent recovery action for active/stuck goals.

Additional notes

Exact app version/platform details were not captured in this report. The behavior was reported from desktop plus iOS mobile usage on 2026-06-16.