iOS Codex remote: Full access selected but new threads start with workspace-write/on-request; Custom config.toml works

What version of the Codex App are you using?

• Codex App: 26.519.41501 (build 3044)
• Bundled Codex CLI in app: 0.133.0-alpha.1
• Standalone Codex CLI / app-server daemon: 0.133.0
• Host OS: macOS 26.5 (25F71), arm64
• Mobile client: ChatGPT iOS app using Codex remote connections, observed through iPhone Mirroring

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS arm64 host connected to ChatGPT iOS through Codex remote access.

What issue are you seeing?

In the ChatGPT iOS Codex remote UI, the composer permissions picker showed Full access selected for the connected Mac host, but new iPhone-created threads still started with restricted permissions:

"approval_policy": "on-request",
"sandbox_policy": {
  "type": "workspace-write",
  "network_access": false,
  "exclude_tmpdir_env_var": false,
  "exclude_slash_tmp": false
}

This caused the mobile-started Codex thread to request command approvals even though the iPhone UI showed Full access.

Switching the same iPhone composer permissions picker from Full access to Custom (config.toml) fixed the issue immediately. The host config is:

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

After selecting Custom (config.toml), newly created iPhone threads started with:

"approval_policy": "never",
"sandbox_policy": {
  "type": "danger-full-access"
}

and commands ran without approval prompts.

Steps to reproduce

1. On a macOS host, configure ~/.codex/config.toml with:

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

1. Start/enable the Codex remote-control daemon for mobile remote access.
2. Open ChatGPT iOS > Codex remote connection to the Mac host.
3. Start a new Codex thread from iPhone.
4. Open the mobile composer permissions picker.
5. Select Full access; verify the picker shows Full access checked.
6. Send a prompt that requires a shell command, for example:

``text
Run this shell command: echo IPHONE_FULL_ACCESS_TEST. Then stop.
``

1. Inspect the resulting host-side rollout/state.

Expected behavior

When the iPhone Codex UI shows Full access, new iPhone-created threads should start with full access:

"approval_policy": "never",
"sandbox_policy": { "type": "danger-full-access" }

No command approval prompts should be required.

Actual behavior

With iPhone Full access selected, the new iPhone-created thread started with:

"approval_policy": "on-request",
"sandbox_policy": {
  "type": "workspace-write",
  "network_access": false
}

This made the thread ask for approvals despite the mobile UI showing Full access.

Workaround

On iPhone, select Custom (config.toml) instead of Full access.

With the host config.toml set to approval_policy = "never" and sandbox_mode = "danger-full-access", this produced the expected full-access runtime. I verified it by creating a fresh iPhone-started thread after switching to Custom (config.toml).

That thread's rollout contained:

"approval_policy": "never",
"sandbox_policy": { "type": "danger-full-access" },
"permission_profile": { "type": "disabled" }

and the model ran:

{
  "cmd": "echo IPHONE_NEW_THREAD_CUSTOM_OK",
  "yield_time_ms": 1000,
  "max_output_tokens": 2000
}

without any sandbox_permissions escalation request. The output was:

IPHONE_NEW_THREAD_CUSTOM_OK

Additional evidence

I also updated existing local thread rows that had stale restricted permissions, but this was not the root fix. The important mobile-side observation is:

• iPhone Full access selected: new iPhone thread persisted as on-request + workspace-write.
• iPhone Custom (config.toml) selected: new iPhone thread persisted as never + danger-full-access.

This looks related to, but not identical to, #22800. That issue mentions Android mobile remote permissions falling back to Default / workspace-write; this report is specifically for iOS where the UI visibly showed Full access selected, but the created thread still used restricted permissions.