Mobile remote continuation can downgrade desktop full-access sessions to managed workspace-write permissions

What happened?

A Codex Desktop session that was running with full access started prompting for approvals after I continued/controlled the same running session from ChatGPT mobile under the Codex section. After returning to the desktop app, the same session continued prompting until I relaunched the agent role into a fresh desktop session.

This has happened multiple times in the last 24 hours. I investigated the local session JSONL and found that the runtime turn context changed from full-access to a managed/restricted profile immediately after a mobile/remote continuation injected a new <environment_context>.

Expected behavior

Remote/mobile control should preserve the connected host/session permission posture. The remote connections docs say the connected host provides the environment and that the connected session's sandboxing settings, security controls, and action approvals still apply.

If a desktop session is running with:

approval_policy = never
sandbox_policy.type = danger-full-access
permission_profile.type = disabled

then continuing that same session from mobile should not silently rehydrate it as:

approval_policy = on-request
sandbox_policy.type = workspace-write
permission_profile.type = managed

Actual behavior

The session's next turn context changed to on-request / workspace-write / managed, and normal commands against the real working repo outside the projectless Codex folder started requiring approval/escalation.

Sanitized local trace

Codex Desktop / CLI version observed in session metadata: 0.142.3.
Codex app build in config env: 26.623.42026.
Host: macOS, Codex Desktop, ChatGPT mobile remote/control involved.

Thread A: orchestrator session

Session/thread id: 019f0e2a-0566-7c93-bfe4-88366a85567f

Before mobile/remote continuation:

2026-06-28T19:18:06.854Z
turn_id=019f0faa-e8fa-7cc3-aaa7-70a315690396
approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled
cwd=/Users/.../Documents/Codex/2026-06-28/continue-from-users-david-borden-dev-2

Immediately after a user-side injected environment context with permission_profile type="managed":

2026-06-28T19:19:40.971Z
turn_id=019f0fac-58a4-77f1-aa68-5a265cc40841
approval_policy=on-request
sandbox_policy=workspace-write
permission_profile=managed
cwd=/Users/.../Documents/Codex/2026-06-28/continue-from-users-david-borden-dev-2

Subsequent turns stayed restricted:

2026-06-28T19:20:46.915Z  on-request / workspace-write / managed
2026-06-28T19:23:11.940Z  on-request / workspace-write / managed
2026-06-28T20:09:47.137Z  on-request / workspace-write / managed

During this restricted window, the actual work repo was outside the projectless Codex workspace:

/Users/.../dev/control/environment-foundation

Normal operations against that repo began requiring escalated permission fields, for example tool calls were emitted with sandbox_permissions: require_escalated and justifications like reading or committing in the control repo outside the current sandbox writable root.

After relaunching the role into a fresh Codex Desktop-created session:

new thread id=019f0fda-d476-73d2-b8fe-9e043de86041
2026-06-28T20:10:30.396Z
approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

Thread B: watcher session

Session/thread id: 019f0e2a-267d-7a40-a266-bdb64fafaea4

Before mobile/remote continuation:

2026-06-28T19:40:19.943Z
turn_id=019f0fbf-4063-7a03-aa53-deb1e48fa9cb
approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled
cwd=/Users/.../Documents/Codex/2026-06-28/open-users-david-borden-dev-control

After injected managed environment context:

2026-06-28T19:52:31.730Z
turn_id=019f0fca-6ae5-7fb1-a7fd-3c0f4be63352
approval_policy=on-request
sandbox_policy=workspace-write
permission_profile=managed

Subsequent restricted turns:

2026-06-28T19:55:20.017Z  on-request / workspace-write / managed
2026-06-28T19:57:01.429Z  on-request / workspace-write / managed
2026-06-28T19:58:13.000Z  on-request / workspace-write / managed
2026-06-28T19:59:05.747Z  on-request / workspace-write / managed

Later, after another environment context with permission_profile type="disabled", the same thread returned to:

2026-06-28T20:11:52.960Z
approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

A fresh watcher relaunch also started correctly:

new thread id=019f0fdc-ab7d-7041-a87e-200742f13f7e
2026-06-28T20:12:29.320Z
approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

Repro shape

1. Start a Codex Desktop session with full access.
2. Verify turn context is approval_policy=never, sandbox_policy=danger-full-access, permission_profile=disabled.
3. Continue/control that same running session from ChatGPT mobile under Codex.
4. Observe next turn contains an injected <environment_context> with permission_profile type="managed" and restricted filesystem write entries for the projectless Codex folder.
5. Observe next turn_context is on-request / workspace-write / managed.
6. Return to desktop and run ordinary repo commands outside the projectless folder; prompts/escalations are now required.
7. Relaunch the same role in a fresh desktop-created session; full-access turn context returns.

Impact

This creates friction and can interrupt long-running orchestrator/watchdog sessions. It also makes the UI/session hard to reason about because the user believes the desktop session is still full access, but the persisted turn context has been downgraded after mobile interaction.

Related issues

This looks related to:

• #24270 (iOS remote/default permission issue)
• #25590 (desktop shows Full Access but runtime is workspace-write/on-request/managed)
• #28296 (resume/rehydration replacing full access with default/managed profile)
• #29915 (permission/profile selection not persisting)

Workaround being tested

Based on adjacent reports, I added explicit global defaults:

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

However, the core issue here appears to be session rehydration/mobile continuation injecting permission_profile type="managed" into an existing full-access session. A config default may help new sessions or Custom profile selection, but it should not be necessary to preserve an already-running session's permission posture.

I can provide additional sanitized turn-context snippets if useful, but I am intentionally not attaching full JSONL logs because they contain private prompts, paths, and tool output.