›_ Codex Issues
Codex Issues / #24270

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

Open 💬 3 comments Opened May 23, 2026 by clamalo
💡 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?

  • 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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22800

Powered by Codex Action

babakd · 1 month ago

I reproduced this on a substantially newer build, and in my case it also affected an existing, actively running desktop-started task.

Environment:

  • ChatGPT/Codex desktop app: 26.707.41301 (build 5103)
  • Bundled Codex CLI: 0.144.0-alpha.4
  • Standalone Codex CLI: 0.144.1
  • Host: macOS 26.3.1 (25D771280a), arm64
  • Client: ChatGPT iOS Remote
  • Reproduced: 2026-07-11

The task was created locally and was already running with Full Access. Its host-side rollout records show:

{"timestamp":"2026-07-11T18:59:58.220Z","approval_policy":"never","sandbox_policy":{"type":"danger-full-access"},"permission_profile":{"type":"disabled"}}
{"timestamp":"2026-07-11T19:21:18.304Z","approval_policy":"never","sandbox_policy":{"type":"danger-full-access"},"permission_profile":{"type":"disabled"}}

After opening the same task through iOS Remote and sending a follow-up with Full Access selected, that phone-originated turn received a different runtime permission envelope:

{"timestamp":"2026-07-11T20:31:57.973Z","approval_policy":"on-request","sandbox_policy":{"type":"workspace-write","network_access":false},"permission_profile":{"type":"managed","network":"restricted"}}

This was not merely an incorrect UI label: the running agent began requesting approval for commands and the autonomous workflow stalled.

After disconnecting Remote and ending that restricted turn, the next desktop/Goal continuation returned to the original permissions:

{"timestamp":"2026-07-11T20:42:02.508Z","approval_policy":"never","sandbox_policy":{"type":"danger-full-access"},"permission_profile":{"type":"disabled"}}

The documented behavior says Remote uses the connected host's permissions and that its sandboxing settings and action approvals continue to apply:
https://learn.chatgpt.com/docs/remote-connections

The Custom (config.toml) workaround works:

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

However, selecting Custom only affects a fresh turn. It does not repair a restricted turn that Remote has already created.

This therefore appears to be a turn-creation/inheritance bug on the mobile Remote path, including for existing desktop-started tasks—not just newly created iPhone tasks.

I can provide the complete redacted rollout records privately if useful.

permanetjv · 1 day ago

Additional reproduction shows the current iOS Remote client also persists this legacy permission state into the remote host config.

Environment: ChatGPT iOS 1.2026.224; Linux remote app-server 0.149.1; client identity logged as codex_chatgpt_ios_remote. The managed host initially had native default_permissions = ":workspace" and no sandbox_mode. After boot, iOS sent config/batchWrite at 18:51:24, 18:53:00, and 18:53:09.450 UTC. The final RPC was followed 2.12 ms later by the ~/.codex/config.toml mtime changing, leaving:

approval_policy = "on-request"
approvals_reviewer = "guardian_subagent"
default_permissions = ":workspace"
sandbox_mode = "workspace-write"

The iOS-started thread was recorded as OnRequest + AutoReview + legacy WorkspaceWrite, with permission_profile=None and active_permission_profile=None. A simultaneously connected macOS client performed config reads but no writes. This creates a mixed native/legacy host configuration and the mobile UI then displays Custom (config.toml). The first write occurred during new-chat initialization, before an explicit profile-selection test, so avoiding the picker alone is not sufficient. The likely fix is for iOS Remote to send native permissions profiles for thread start/resume and not synchronize chat permission presets into host config.toml via config/batchWrite.