/goal continuation uses stale permission context after permissions changes

Resolved 💬 8 comments Opened May 11, 2026 by 2c67cc18 Closed May 24, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

/goal can start autonomous continuation with an older core permission context after the TUI permission mode has changed.

Observed effect: permission prompts can appear during goal continuation even after selecting Full Access, or approval routing can remain user-facing after selecting Auto-review.

A fresh session with Full Access or Auto-review as the default can work, which points to stale runtime permission state after an in-session permission change.

What steps can reproduce the bug?

Start Codex with the goals feature enabled.
In the TUI, change permissions to Full Access or Auto-review.
Set a goal with /goal <objective>.
Let goal continuation start work that would otherwise trigger a permission or approval path.
Observe that continuation can use the previous approval policy, reviewer, or permission profile.

What is the expected behavior?

/goal continuation should use the current TUI permission context:

current approval policy
current approvals reviewer
current permission profile
current active permission profile

Additional information

Root-cause hypothesis: thread/goal/set carries goal fields only, while turn/start carries permission context through turn-context overrides. When /goal activates a goal and immediately starts continuation, core can continue from stale session settings.

Reference patch branch:
https://github.com/openai/codex/compare/main...2c67cc18:codex:fix-goal-permission-context

Local verification for the patch:
RUSTUP_TOOLCHAIN=stable cargo check -p codex-core -p codex-app-server -p codex-tui passed.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#21839

Powered by Codex Action

leofratu · 2 months ago

have the same issue

Wenjunyun123 · 1 month ago

I investigated this locally and prepared a PR-ready fix branch here:

Branch: https://github.com/Wenjunyun123/codex/tree/fix-goal-resume-auto-review
Compare: https://github.com/openai/codex/compare/main...Wenjunyun123:codex:fix-goal-resume-auto-review?expand=1
Commit: e69360be9b82a173f6ae2dd52173cc8144367fa2

Root cause I found:

The cold resume path applies runtime/config overrides.
The running-thread resume path only logged override mismatches and kept using the existing thread's stale SessionConfiguration.
Goal continuation is triggered immediately after resume, so /goal could continue with the old permission prompt/config even after the client resumed with approvalsReviewer: "auto_review" or updated permissions.

Fix approach in the branch:

Apply supported resume-time overrides to the active running thread before returning the resume snapshot or triggering goal continuation.
Update active session settings for model/provider/cwd/runtime workspace roots/approval policy/approvals reviewer/sandbox or permissions/personality.
Keep per-turn permission config synchronized with the refreshed active session approval policy.
Add regression coverage that captures the actual /goal continuation request and asserts it carries the refreshed auto-review permission context instead of the stale one.

Validation run locally:

cargo fmt
git diff --check
cargo check -p codex-core -p codex-app-server
cargo test -p codex-app-server thread_resume_applies_overrides_to_running_thread --test all
cargo test -p codex-app-server thread_resume_goal_continuation_uses_running_thread_overrides --test all

I noticed docs/contributing.md says external code contributions are by invitation only, and my account could not create a PR against openai/codex via GitHub API (CreatePullRequest permission denied). Leaving the branch/compare link here in case it is useful to the maintainers or can be invited into a PR.

etraut-openai contributor · 1 month ago

This issue has been fixed in 0.133.0. If you're still seeing behavior like this with the latest version, please open a new bug report with repro details.

ilgaur · 1 month ago

I'm still seeing this on MacOS desktop app. I'm on Version 26.519.41501 (3044).

etraut-openai contributor · 1 month ago

@ilgaur, we're still working on a fix for this in the app. It was fixed in the TUI in 0.133.0.

peteallen · 1 month ago

@ilgaur, we're still working on a fix for this in the app. It was fixed in the TUI in 0.133.0.

Any update on this? Is there a separate issue to track this in the desktop app? It's severely hindering long-running goals.

etraut-openai contributor · 1 month ago

Still working on the fix. It's complex and requires more testing before we release it.

In the meantime, you can work around the problem by issuing a regular user prompt (not a goal) after changing the permissions in a thread. Then once you create the goal, it will properly inherit the permissions from the previous turn. The bug occurs when you change the permissions (or start a new thread from scratch) and immediately thereafter create a new /goal.