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

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