›_ Codex Issues
Codex Issues / #24440

macOS remote sessions cannot write to external-volume workspaces on 0.130/0.132/0.133 (Operation not permitted)

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

What version of Codex CLI is running?

Reproduced with:

codex-cli 0.132.0
codex-cli 0.133.0

What subscription do you have?

ChatGPT Pro Lite

Which model were you using?

Not model-specific. The failure happens at shell/filesystem command execution time before normal task logic matters.

What platform is your computer?

ProductName:    macOS
ProductVersion: 26.4.1
BuildVersion:   25E253

uname -mprs:
Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Remote Codex session from ChatGPT iOS / SSH-Local style connection into a macOS host.

What issue are you seeing?

In a remote Codex session on macOS, shell commands cannot write to a normal workspace located under an external-volume path:

/Volumes/Data/Github/macOSAgentBot

The error is consistently:

Operation not permitted

This is not a generic Unix ownership/mode problem. The current user is ronnie, and the target workspace is also owned by ronnie. Writes to /tmp and to /Users/ronnie/... succeed in the same remote session, while writes under /Volumes/Data/Github/... fail.

Observed failure shape:

mkdir -p codex-rw-test && pwd && ls -ld codex-rw-test

# Output included:
mkdir: codex-rw-test: Operation not permitted

Using the absolute workspace path fails the same way:

mkdir -p /Volumes/Data/Github/macOSAgentBot/codex-rw-test
# => mkdir: /Volumes/Data/Github/macOSAgentBot/codex-rw-test: Operation not permitted

mkdir -p /Volumes/Data/Github/.codex-rw-test-parent
# => mkdir: /Volumes/Data/Github/.codex-rw-test-parent: Operation not permitted

But equivalent writes outside the external-volume workspace work:

mkdir -p /tmp/codex-rw-test && printf "probe\n" > /tmp/codex-rw-test/probe.txt
# => succeeds

mkdir -p /Users/ronnie/codex-rw-test && printf "read-write-ok\n" > /Users/ronnie/codex-rw-test/probe.txt
# => succeeds

I also checked the target directory ownership and basic permissions from the session. The evidence points to an extra macOS protection / remote execution permission boundary affecting /Volumes/Data/Github writes, not ordinary POSIX permissions.

What steps can reproduce the bug?

  1. On macOS, use Codex CLI 0.132.0 or 0.133.0.
  2. Start a remote Codex session through ChatGPT iOS / SSH-Local style access to the macOS host.
  3. Use a workspace located on an external volume, for example:

``text
/Volumes/Data/Github/macOSAgentBot
``

  1. Ask Codex to create a test folder in the workspace, or run:

``sh
mkdir -p codex-rw-test
``

  1. Observe Operation not permitted.
  2. Run equivalent writes under /tmp or /Users/<user>/...; those succeed.

What is the expected behavior?

If the remote Codex session is allowed to operate in the workspace and the workspace is owned by the same macOS user, Codex should be able to create files and folders there, or it should surface a clear actionable macOS permission message explaining which process/app/executable needs Full Disk Access or external-volume access.

Additional information

This is specifically about the behavior observed on 0.132.0 and 0.133.0. I had previously worked around a similar failure by downgrading, but after retesting 0.133.0 the same Operation not permitted behavior still occurs for the external-volume workspace.

The important distinction is that the same remote session can write to /tmp and /Users/ronnie, but not to /Volumes/Data/Github, even though the directory owner is the same user.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #22785

Powered by Codex Action

qoli · 1 month ago

Update: I can also reproduce this class of failure with codex-cli 0.130.0, but the important scope is narrower than plain macOS filesystem access:

This happens in the ChatGPT iOS / SSH-Local remote session path.

The chronology is important:

  1. I previously hit this on codex-cli 0.132.0.
  2. Downgrading from 0.132.0 to 0.130.0 made the problem go away at that time.
  3. After testing 0.133.0, the same Operation not permitted problem still reproduced.
  4. Downgrading back to 0.130.0 this time did not fix it.

So CLI version alone does not explain the behavior. Something in the ChatGPT iOS / SSH-Local remote execution path, managed permission profile, or macOS permission context appears to be part of the trigger.

The current 0.130 repro session is:

019e5f01-e128-7433-834f-66e42152e98c

That session metadata shows:

originator: codex_chatgpt_ios_remote
cwd: /Volumes/Data/Github/macOSAgentBot
cli_version: 0.130.0

The turn context for the failing write shows the remote managed permission profile:

approval_policy: on-request
sandbox_policy: workspace-write
permission_profile: managed / restricted filesystem

In that ChatGPT iOS SSH remote session, writes under /Volumes/Data/Github/... failed with Operation not permitted, while writes under /private/tmp worked. The directory listing showed the target workspace was owned by the same user (ronnie) and /Volumes/Data was mounted read-write, so this does not look like a plain POSIX owner/mode problem.

Important contrast: in a separate local Codex execution environment on the same Mac, also using codex-cli 0.130.0, I can successfully write to /Volumes/Data/Github/.... So the current evidence points specifically to the ChatGPT iOS / SSH-Local remote managed sandbox or macOS permission context around external-volume workspaces.

qoli · 1 month ago

Additional profile comparison: this now looks strongly tied to the runtime permission profile, not only the Codex CLI binary version.

A previous session from 2026-05-22, where downgrading away from 0.132.0 to 0.130.0 restored normal behavior, had this turn context:

cwd: /Volumes/Data/Github/macOSAgentBot
approval_policy: never
sandbox_policy: danger-full-access
permission_profile: disabled

The current failing 0.130.0 ChatGPT iOS / SSH-Local remote session (019e5f01-e128-7433-834f-66e42152e98c) has this turn context:

cwd: /Volumes/Data/Github/macOSAgentBot
approval_policy: on-request
sandbox_policy: workspace-write
permission_profile: managed / restricted filesystem
network: restricted

So the same nominal CLI version (0.130.0) can behave differently depending on the remote runtime profile. This likely explains why an earlier rollback to 0.130 fixed the issue, but the later rollback to 0.130 did not: the ChatGPT iOS / SSH-Local remote profile appears to have changed.

qoli · 1 month ago

Correction to the previous profile hypothesis: workspace-write itself is not the root explanation. workspace-write is supposed to allow writes to the project root.

I created another fresh ChatGPT iOS / SSH-Local remote session that proves the failure also happens under danger-full-access with permission_profile: disabled:

session id: 019e5f07-0479-77d1-b74d-c641e22049ee
originator: codex_chatgpt_ios_remote
cwd: /Volumes/Data/Github/macOSAgentBot
cli_version: 0.130.0
approval_policy: never
sandbox_policy: danger-full-access
permission_profile: disabled

Even in that session, commands in the workspace failed:

pwd
# => pwd: .: Operation not permitted

mkdir -p codex-rw-test
# => mkdir: codex-rw-test: Operation not permitted

So the better scoped issue is: ChatGPT iOS / SSH-Local remote sessions on macOS cannot access/write an external-volume workspace under /Volumes/Data/Github/..., even when the reported runtime profile is danger-full-access and permission profiles are disabled.

This makes the behavior unlikely to be caused by workspace-write policy alone. The failure appears to be below or outside the declared Codex sandbox/profile layer, likely in the remote session process context or macOS external-volume/TCC access path.

qoli · 1 month ago

Control test: Codex Desktop remote on the same machine and same workspace can write successfully.

Working control session:

session id: 019e5f0a-f4c1-7a92-bf43-c8ffe7bada1a
originator: Codex Desktop
cwd: /Volumes/Data/Github/macOSAgentBot
cli_version: 0.133.0-alpha.1
approval_policy: never
sandbox_policy: danger-full-access
permission_profile: disabled

In that Codex Desktop session, the same external-volume workspace successfully created and wrote a probe file:

folder=.tmp/codex-rw-test-20260525-201100
file=.tmp/codex-rw-test-20260525-201100/read_write_check.txt
read_back=codex read/write test
created_at=2026-05-25T20:11:00+08:00
size_bytes=74
sha256=ecca966aa23f7287d45b49b97fdfb737d10458acc8153b4575afd100ef432dbe

This is the strongest scope so far:

  • Failing: codex_chatgpt_ios_remote / ChatGPT iOS SSH-Local originator, same macOS host, same /Volumes/Data/Github/macOSAgentBot workspace.
  • Working: Codex Desktop originator, same macOS host, same workspace, danger-full-access, permission_profile: disabled.

So the issue appears specific to the ChatGPT iOS / SSH-Local remote originator or its spawned process context, not to the external volume itself, not to the workspace permissions, and not to danger-full-access being unavailable in general.

qoli · 1 month ago

Update: I found the working mitigation and the actual process chain for the ChatGPT iOS SSH Remote case.

The failing path was not caused by Codex sandbox settings. The failing test thread was:

  • 019e5f2e-bb2f-7f81-8df6-faa094845c9a
  • originator=codex_chatgpt_ios_remote
  • cwd=/Volumes/Data/Github/macOSAgentBot
  • cli_version=0.130.0
  • sandbox_policy=danger-full-access
  • permission_profile=disabled
  • failures included mkdir: Operation not permitted, ls: Operation not permitted, and fatal: Unable to read current working directory: Operation not permitted

After inspecting the live macOS process tree, the ChatGPT iOS SSH Remote path was:

ChatGPT iOS SSH Remote
-> sshd-session
-> nc -U /Users/ronnie/.codex/app-server-control/app-server-control.sock
-> /opt/homebrew/bin/codex app-server --listen unix://

So the relevant long-lived process was not the GUI Codex.app and not VS Code. It was the Homebrew Codex app-server listening on ~/.codex/app-server-control/app-server-control.sock.

In my case, that app-server process had been started on May 22, before I granted Full Disk Access to the Homebrew Codex binary and sshd-session. It kept producing app-server log entries such as:

failed to read skills dir /Volumes/Data/Github/macOSAgentBot/.codex/skills: Operation not permitted (os error 1)
error trying to find AGENTS.md docs: Operation not permitted (os error 1)

The mitigation that made ChatGPT iOS SSH Remote work again was:

  1. Grant Full Disk Access to the Homebrew Codex binary:

/opt/homebrew/Caskroom/codex/0.130.0/codex-aarch64-apple-darwin

  1. Grant Full Disk Access to:

/usr/libexec/sshd-session

  1. Restart the managed app-server:

/opt/homebrew/bin/codex app-server --listen unix://

  1. Reopen the ChatGPT iOS SSH Remote session.

After restarting that app-server, the follow-up test thread succeeded:

  • 019e5f35-6164-7193-9c0a-63b3e0949d69

This explains why simply changing Full Disk Access was not enough: the existing long-lived app-server process still had the old macOS TCC permission state until it was restarted.

qoli · 1 month ago

Follow-up: confirmed the same mitigation works on Codex 0.133.0 as well.

Validation thread:

  • 019e5f3d-e904-7f20-97c5-ceb97633b9d7
  • Codex TUI / Homebrew cask: codex-cli 0.133.0
  • ChatGPT iOS SSH Remote workspace on /Volumes/Data/Github/...
  • The read/write test passed after applying the mitigation.

One correction/clarification to my previous comment: for the final validation I did not manually keep an app-server running. The better validation path was:

  1. Upgrade Homebrew Codex to 0.133.0.
  2. Grant Full Disk Access to the new physical cask binary path:

/opt/homebrew/Caskroom/codex/0.133.0/codex-aarch64-apple-darwin

  1. Keep Full Disk Access for /usr/libexec/sshd-session.
  2. Kill existing sshd-session, nc -U ~/.codex/app-server-control/app-server-control.sock, and /opt/homebrew/bin/codex app-server --listen unix:// processes.
  3. Let the ChatGPT iOS app create the new SSH Remote session and app-server on its own.

With that flow, 0.133.0 successfully picked up the workaround and the external-volume workspace became writable again.

So the practical mitigation is still: update the Full Disk Access entry whenever the Homebrew cask binary path changes, then fully restart the SSH Remote/app-server process chain so macOS TCC permissions are applied to the newly spawned process.