›_ Codex Issues
Codex Issues / #29054

Full access mode still asks for approval after reconnecting to a remote environment

Open 💬 3 comments Opened Jun 19, 2026 by KomorebiWerts
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.3767.0

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When using the Codex desktop app with a remote environment in Full access mode, Codex sometimes still asks for approval before running commands.

This happens even though the session is configured with:

  • Filesystem sandboxing: danger-full-access / Full access
  • Approval policy: never / no approval expected

The issue appears most often after either:

  • Restarting the Codex desktop app
  • The remote connection being reset or reconnected

After reconnecting, the session appears to lose or desynchronize its permission state. The UI/configuration still indicates Full access, but command execution behaves as if approval is required.

Feedback ID: 019edea8-c39d-7c52-a0ca-6c80ece7b330

What steps can reproduce the bug?

Feedback ID: 019edea8-c39d-7c52-a0ca-6c80ece7b330

What is the expected behavior?

After the Codex desktop app restarts, or after a remote connection is reset and reconnected, the session should continue to honor the configured Full access mode.

Commands that are allowed under Full access should run without asking for additional approval.

Additional information

This seems like the app or remote session is not correctly restoring or synchronizing the sandbox/approval state after reconnection.

The issue is disruptive for long-running or automated development workflows because the user has to manually approve actions that should already be allowed by the selected Full access mode.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28296
  • #29043
  • #28988
  • #27803

Powered by Codex Action

mow-coding · 2 months ago

I’m seeing a very similar issue on Codex Desktop for Windows.

Environment:

  • Codex Desktop package: 26.616.3309.0
  • Codex CLI/runtime: 0.142.0-alpha.1
  • OS: Windows 11 Education, Windows NT 10.0.26200 x64
  • UI shows Full access in the composer.

Symptom:

  • Most threads behave correctly with Full access.
  • One specific resumed thread kept asking for approval on almost every action.
  • The composer still displayed Full access, but the resumed turn was injected as workspace-write/on-request.

What I checked:

~/.codex/config.toml contains:

approval_policy = "never"
sandbox_mode = "danger-full-access"

codex doctor --summary reports:

sandbox: unrestricted fs + enabled network · approval Never

.codex-global-state.json had the thread heartbeat permission set to:

approvalPolicy = never
sandboxPolicy.type = dangerFullAccess
activePermissionProfile.id = :danger-full-access

But the same thread’s row in state_5.sqlite still had:

approval_mode = on-request
sandbox_policy = {"type":"managed", ... restricted filesystem ..., "network":"restricted"}

And the resumed session log showed:

approval_policy: on-request
sandbox_policy: workspace-write
permission_profile: managed

Interesting detail:

The thread had previously been running with:

approval_policy: never
sandbox_policy: danger-full-access
permission_profile: disabled

After resuming the same thread later, it switched to:

approval_policy: on-request
sandbox_policy: workspace-write
permission_profile: managed

This seems thread-specific rather than global, because new/current threads can still run as Full access.

Local workaround attempted:

  • Updating config.toml alone did not fix the affected resumed thread.
  • Updating .codex-global-state.json alone did not fix it.
  • The affected thread also had to be corrected in state_5.sqlite from on-request/managed to never/disabled.
  • Already-running approval-pending turns still needed to be cancelled/restarted.

This looks like a thread-level permission state desync between the Desktop UI/global state and the persisted thread row used when resuming a thread.

roni-estein · 23 days ago

Confirmed on macOS with the Codex desktop/remote handoff on 2026-08-04. The originating Codex UI visibly showed Full access in the composer, but the resumed remote turn was injected with sandbox_mode=workspace-write, approval_policy=on-request, and permission_profile=managed. The agent could read the filesystem but only write inside an unrelated workspace root, so Git/Simulator/project edits prompted repeatedly.

No permission setting was changed by the user. On the next handoff/message, the same thread was injected correctly again as danger-full-access, approval_policy=never, permission_profile=disabled, and the prompts disappeared. This matches the thread-level permission state desynchronization described above, but reproduces on macOS and specifically across a phone/laptop remote continuation. I also have a contemporaneous photo showing the composer still displayed Full access while the restricted profile was active.