[Desktop Remote/SSH] Opening a cross-linked task silently downgrades the remote thread from Full Access

What version of the Codex App are you using?

Codex Desktop build 26.803.41515, with bundled codex-cli 0.147.0-alpha.6.5.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Reproduced across three Apple Silicon Macs, all running:

macOS 26.5.2 (25F84)
arm64

What issue are you seeing?

Opening an existing task through a different Mac's saved Remote/SSH project can silently replace that task's persisted Full Access posture on its authoritative host.

Before the remote view, the task is correctly persisted and executing as:

approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled
active_permission_profile=null

Simply opening/resuming the same task through a cross-linked route such as:

/local/<thread-id>?hostId=remote-ssh-discovered:<other-host>

causes the authoritative remote task to emit thread_settings_applied with:

approval_policy=on-request
permission_profile=managed
active_permission_profile=:workspace
filesystem=restricted
network=restricted

The authoritative host's ~/.codex/state_5.sqlite thread row is also changed to the restricted posture. This is therefore a persistent settings mutation, not only a stale or incorrect UI label.

No permission selector is changed, and sending a prompt is not required. The mutation occurs during the Desktop view/resume path itself. A task can be changed even while an already-started Full Access turn is running.

All three hosts had identical explicit defaults:

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

Tasks viewed through their native host/project do not show this downgrade pattern. Cross-linked Remote/SSH views do.

What steps can reproduce the bug?

1. Configure two Macs, Host A and Host B, with approval_policy = "never" and sandbox_mode = "danger-full-access".
2. Create an existing Codex task on Host A with explicit Full Access.
3. Confirm on Host A that the rollout and state DB record never / danger-full-access / disabled.
4. On Host B, open Host A's saved Remote/SSH project.
5. Open the existing Host A task through the remote-ssh-discovered:Host-A route. Do not change permissions.
6. Inspect the task's rollout and state DB on Host A.
7. Observe that the task has been changed to on-request / workspace-write / managed / :workspace.
8. Later operations begin waiting for approvals despite the task having been created as Full Access.

Sanitized deterministic evidence

The issue reproduced three times with three distinct existing tasks and two different viewer/remote-host pairings:

Viewer Host B -> task on Host A
view activity:          18:37:12.598Z
thread_settings_applied 18:37:12.864Z
delta:                  266 ms

Viewer Host B -> task on Host C
view activity:          18:38:10.934Z
thread_settings_applied 18:38:11.080Z
delta:                  146 ms

Viewer Host C -> task on Host A
view activity:          19:11:46.584Z
thread_settings_applied 19:11:46.933Z
delta:                  349 ms

The Desktop diagnostic line after the cross-linked thread/resume consistently contained:

derivedActivePermissionProfile=null
derivedApprovalPolicy=on-request
derivedSandboxPolicy=workspaceWrite
hasCurrentPermissions=false
hasExplicitPermissions=false
requestApprovalPolicy=null
requestPermissionProfile=null
requestSandboxMode=null
responseActivePermissionProfile=:workspace
responseApprovalPolicy=on-request
shouldSendPermissions=false

The important contradiction is that the viewer sent no explicit permission request and logged shouldSendPermissions=false, yet the remote task returned and persisted :workspace / on-request.

As a control, current native-host resumes for the same tasks use:

derivedApprovalPolicy=never
requestApprovalPolicy=never
responseActivePermissionProfile=null
responseApprovalPolicy=never
shouldSendPermissions=true

and remain Full Access.

What is the expected behavior?

Opening or reading an existing task through Remote/SSH must not mutate its persisted sandbox or approval posture.

If the resume request contains no explicit permission fields, the connected host's existing per-thread settings should remain authoritative. A viewer/project default must not replace them.

If Codex cannot safely reconcile permission state, it should refuse the resume visibly rather than silently downgrade the remote task and cause later approval waits.

Impact

This interrupts multi-host and long-running workflows. Tasks created for unattended Full Access operation can start waiting for approval solely because someone inspected them from another host. The wait is easy to miss and can stall coordinated work for hours.

Related issues

This appears related to, but more specific than:

• #25590 — Desktop resume persists workspace-write while UI shows Full Access
• #29054 — remote reconnect can lose Full Access
• #30485 — mobile remote continuation downgrades desktop sessions
• #28296 — goal continuation changes permission profile after restart

This report adds a deterministic Desktop Remote/SSH trigger, three cross-host reproductions, the exact maybe_resume_success decision fields, and proof that the authoritative remote thread row is mutated without an explicit permission request.