›_ Codex Issues
Codex Issues / #37229

Codex CLI 0.146.1: PyCharm terminal + macOS Documents + subagents can lose permissions and fail with invalid cwd (EPERM)

Open 💬 3 comments Opened Aug 6, 2026 by forrestzhu

What version of Codex CLI is running?

codex-cli 0.146.1 (npm installation)

What subscription do you have?

ChatGPT-authenticated CLI. Exact plan omitted because this appears to be a local CLI/sandbox regression.

Which model were you using?

gpt-5.6-sol

What platform is your computer?

macOS 15.7.4 (24G517), arm64

What terminal emulator and version are you using?

PyCharm 2026.1.4 integrated terminal, zsh.

Codex doctor report

Not attached because the full report contains local paths and environment metadata. The relevant sanitized results are:

  • Codex version: 0.146.1
  • Installation: OK
  • Config load: OK after the workaround below
  • State database integrity: OK
  • Sandbox helper check: OK
  • MCP configuration consistency: OK

What issue are you seeing?

On macOS, Codex CLI sessions launched from a PyCharm integrated terminal for a project under ~/Documents can repeatedly lose their effective permissions after subagent activity. In the latest occurrence, this happened around a task that changed Codex hook configuration. Starting a new thread/turn then failed because Codex treated the valid current working directory as invalid:

failed to refresh config before thread transition; continuing with current in-memory config
error=Failed to rebuild config for cwd /Users/REDACTED/Documents/PROJECT
action="starting a new thread"

turn/start failed in TUI
turn/start failed: invalid cwd: Operation not permitted (os error 1) (code -32600)

The directory still existed, was canonical, had normal Unix read/traverse permissions, and could be entered from another shell. PyCharm also had macOS Documents Folder access. This does not look like a missing executable or ordinary filesystem-mode problem: codex --version worked, and Codex could launch from the same directory after disabling hooks and restarting.

This pattern has occurred multiple times specifically with the combination of:

  • PyCharm integrated terminal
  • a project below ~/Documents
  • Codex subagents

The user-visible effect is broader than one denied command: the running workflow appears to lose permissions, and a subsequent thread/turn can fail at cwd validation.

What steps can reproduce the bug?

The failure is recurring but appears timing/state dependent. The repeatedly observed sequence is:

  1. Open a local project below ~/Documents in PyCharm on macOS.
  2. Start Codex CLI from PyCharm's integrated zsh terminal.
  3. Use gpt-5.6-sol and ask Codex to delegate work to subagents.
  4. During the session, run a task that changes Codex hook configuration.
  5. Start a new thread or submit the next turn.
  6. Observe that effective permissions have become restricted/unavailable and the TUI fails with invalid cwd: Operation not permitted (os error 1).

Local logs show one concrete sequence:

T+00s  failed to refresh config before thread transition for /Users/REDACTED/Documents/PROJECT
T+59s  turn/start failed: invalid cwd: Operation not permitted (os error 1)

No earlier codex_tui::app::event_dispatch invalid cwd entry was present in the local log database before upgrading to 0.146.1.

What is the expected behavior?

  • Subagents should inherit the parent session's effective sandbox/permission policy.
  • Hook configuration changes should not invalidate or downgrade the current working directory.
  • A valid, accessible project below ~/Documents should remain usable from PyCharm's terminal across subagent and new-thread transitions.
  • If Codex intentionally changes the effective permission profile, the new state should be explicit and should not make thread/start fail cwd validation.

Additional information

The CLI was upgraded to 0.146.1 on the day of the latest occurrence. The 0.146.1 release contains a single permission-related backport, #37057, which changes active TUI thread permission defaults and code in event_dispatch.rs, thread_settings.rs, and app_server_session.rs. The failure is also reported from the TUI thread-start path. This correlation may be relevant, but it is not presented as a proven root cause.

Related permission-state reports include #25810 and #32763, but neither covers this exact macOS CLI + PyCharm + ~/Documents + subagent/hook path or the invalid cwd failure.

Current local workaround:

[features]
hooks = false

After restarting Codex with hooks disabled, the same cwd could be opened successfully. This is a workaround observation, not proof that hooks alone are the root cause.

For privacy, raw logs, thread/process IDs, absolute user paths, project names, MCP server names, hook command paths, and the full doctor report are intentionally omitted. I can provide additional narrowly scoped, sanitized diagnostics if maintainers identify a specific field they need.

View original on GitHub ↗

3 Comments

forrestzhu · 16 days ago

Update (2026-08-12): reproduced outside PyCharm; TCC attribution-chain failure coincides with the first EPERM

I reproduced the same broader failure today from a normal iTerm2 shell, so PyCharm is not required.

Sanitized environment:

  • macOS 15.7.4 (24G517), arm64
  • iTerm2 3.6.11 with zsh
  • The already-running session was created with Codex CLI 0.146.1
  • The installed CLI had been upgraded in place to 0.147.0 about 2h20m before the failure
  • Project path: ~/Documents/REDACTED/PROJECT
  • The affected turn context remained sandbox_mode = "danger-full-access", with the project trusted and no filesystem permission profile enabled

Exact timeline from the sanitized session log:

16:11:57.446  File contents read successfully.
16:12:16.042  apply_patch read the target file, but failed only because the expected context did not match.
16:12:31.813  A second apply_patch started.
16:12:31.835  macOS tccd failed to identify the accessing process and failed to create the attribution chain.
16:12:31.837  sandboxd reported that the Documents Folder authorization request failed.
16:12:31.847  apply_patch returned: Failed to read file to update ... Operation not permitted (os error 1).
16:12:35.136  File metadata could still be stat'ed, but file contents/directory enumeration were denied.
16:12:47.340  xattr and Git failed; Git reported: Unable to read current working directory: Operation not permitted.
16:13:30.921  The parent workspace and a sibling repository under the same Documents subtree were also denied.

The relevant macOS unified-log lines, with the ephemeral PID removed, are:

tccd: proc_pidpath_audittoken() failed from PID[REDACTED]: (#2) No such file or directory
tccd: Failed to build 'accessingProcess' from indirect_object_token in message from com.apple.sandboxd
tccd: Failed to create attribution chain from message.
sandboxd: tcc_server_message_request_authorization(kTCCServiceSystemPolicyAllFiles) failed: missing 'auth_value' in reply message
sandboxd: tcc_server_message_request_authorization(kTCCServiceSystemPolicyDocumentsFolder) failed: server error: Failed to create Attribution Chain from message.

Additional observations:

  • In the complete tccd log from 15:00-17:00, this was the only proc_pidpath_audittoken / attribution-chain failure. It is therefore not a high-frequency background warning on this machine.
  • The user TCC database already had auth_value=2 (allow) for iTerm2's Documents Folder access. The OpenAI Codex app also had an allow row. There was no direct codex CLI row. This was not a normal stored “Documents access denied” decision; TCC failed before it could construct the responsible-process chain.
  • Unix ownership and mode bits were normal. Codex project trust and the configured sandbox mode did not change during the turn.
  • A fresh codex resume REDACTED_SESSION_ID from the same cwd at 16:34:17, now using CLI 0.147.0, immediately returned Error: Operation not permitted (os error 1). At that point hooks = false was configured, so disabling hooks did not recover the already-failing cwd state.
  • An enterprise EndpointSecurity client was present, but the unified logs contain no corresponding file-access deny. It logged generic process classification/tagging only. I cannot rule out timing influence, but there is no evidence that it issued the denial.
  • The in-place npm upgrade left the already-running 0.146.1 process mapped to the old package directory after npm atomically renamed it. That may be relevant to code identity/provenance, but the long delay means I am not claiming the upgrade directly caused the failure.

Current evidence-based hypothesis: this is a macOS TCC/responsible-process attribution race involving a short-lived Codex tool/helper process. The process had exited before tccd resolved its audit token, so the Documents Folder request failed closed with EPERM. From the CLI side, keeping a stable responsible process/audit identity for protected-folder accesses (or avoiding a short-lived process that can disappear before TCC attribution completes) may be worth investigating.

I can provide a more narrowly scoped, sanitized unified-log excerpt if a maintainer needs additional TCC fields.

forrestzhu · 16 days ago

Root cause confirmed and fix prepared

The short-lived-helper hypothesis in my earlier update was not the root cause. (#2) No such file or directory is ENOENT, and the evidence points to the still-running Codex executable itself losing its filesystem path after the in-place npm upgrade:

  • affected live Codex processes returned proc_pidpath(...) = 0 with errno 2
  • lsof showed those executables mapped from npm's retired .codex-* package directory after that directory had been unlinked
  • in a controlled macOS probe, unlinking a running executable reproduced the same proc_pidpath/ENOENT result
  • preserving a per-session executable path made proc_pidpath continue to return that path with errno 0 after deleting the simulated installed runtime

That explains the TCC sequence directly: tccd cannot resolve the executable path, cannot construct the responsible-process attribution chain, and the Documents request fails closed with EPERM. PyCharm, hooks, subagents, cwd validation, and Codex sandbox policy are not required to trigger it.

I prepared a focused fix that launches npm-managed macOS sessions from a per-session hard-linked native runtime under CODEX_HOME/tmp/native-runtime, preserving the binary and bundled resources across in-place upgrades. It includes PID-based fail-safe lifecycle cleanup, concurrent-session coverage, Node 16 coverage, repo-checks integration, staged npm-package validation with the real darwin-arm64 payload, and an isolated native proc_pidpath probe.

Commit: https://github.com/forrestzhu/codex/commit/c0ec2ae5fe8e78dd5927c2f5610fd85cfa742fee

Compare: https://github.com/openai/codex/compare/main...forrestzhu:codex:fix/macos-npm-stable-runtime

I attempted to open the upstream PR through both the GitHub CLI/API and the signed-in browser. GitHub reports that this repository currently limits opening pull requests to collaborators, so my account cannot create it. If a maintainer can grant the required permission, I can submit the prepared PR immediately; alternatively, please feel free to take over/cherry-pick the commit.

zhengx18 · 7 days ago

Additional confirmation on 0.148.0 and resume-cwd UX

A separate user report still sees the exact TUI failure on the npm-distributed macOS CLI:

Failed to start turn: turn/start failed in TUI: turn/start failed: invalid cwd: Operation not permitted (os error 1) (code -32600)

Sanitized environment:

  • codex-cli 0.148.0, npm installation
  • macOS 15.1.1, arm64
  • Apple Terminal 455 with zsh
  • project below ~/Documents
  • project marked trusted
  • current cwd exists, is canonical, and all ancestors are traversable
  • strict config load, state DB integrity, thread inventory, auth, and WebSocket checks pass

The local thread inventory also contained two non-archived sessions whose saved cwd no longer existed: one deleted temporary directory and one repository that had moved to a new path. Archiving those sessions and setting:

[tui]
resume_cwd = "current"

mitigates the stale-session path, but it does not address the confirmed in-place npm upgrade/TCC attribution root cause documented above.

Two defensive improvements may help in addition to preserving a stable per-session native runtime:

  1. codex update should detect or warn about active Codex processes before replacing the npm-managed runtime.
  2. Resume/start cwd validation should distinguish a missing saved cwd from TCC EPERM, show the rejected sanitized path/source, and offer to fall back to the current cwd instead of failing the turn with only invalid cwd.

The pre-turn failure was not recorded in thread_turns.error_json or the normal desktop log files, so preserving a sanitized diagnostic event for this path would also make future reports easier to verify.