Codex Desktop intermittently loses macOS Documents workspace access despite workspace root being granted

What version of the Codex App are you using (From "About Codex" dialog)?

26.825.41651

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm
macOS 26.3.1

What issue are you seeing?

Codex Desktop intermittently loses access to local project folders under ~/Documents, even when the workspace appears to be selected/attached and the directory itself is visible.

The failure mode is not a normal Unix permission issue. The affected directories are owned by the current user and have normal permissions, but Codex can only stat the workspace root and then fails to read/list child paths with Operation not permitted.

Observed examples:

1. Workspace:

   /Users/<user>/Documents/final/ontology-dashboard
   

   During the failure, commands such as sed, rg, git status, and apply_patch failed with Operation not permitted or could not read the current working directory.

   The directory itself was visible:

   drwxr-xr-x@ 33 <user> staff ... /Users/<user>/Documents/final/ontology-dashboard
       com.apple.macl
       com.apple.provenance
   

   But reading child paths failed, for example:

   ls: /Users/<user>/Documents/final/ontology-dashboard/scripts: Operation not permitted
   

   Re-attaching/reselecting the folder in the Codex app restored access in the same conversation.

2. Another local workspace:

   /Users/<user>/Documents/portfolio
   

   The directory itself was visible:

   drwxr-xr-x 10 <user> staff ... /Users/<user>/Documents/portfolio
   

   But listing the directory failed:

   ls: /Users/<user>/Documents/portfolio: Operation not permitted
   

This also coincided with Codex CLI emitting:

WARNING: proceeding, even though we could not create PATH aliases: Operation not permitted (os error 1)

The CLI itself still ran after reinstalling/updating:

codex-cli 0.151.0

This looks like a mismatch between the Codex Desktop workspace permission state and the effective macOS sandbox/TCC access available to the running session.

What steps can reproduce the bug?

The issue is intermittent, but I observed it across multiple local Codex Desktop sessions using project folders under ~/Documents.

1. Open Codex Desktop on macOS.

2. Open or continue a local task whose workspace is under ~/Documents, for example:

   /Users/<user>/Documents/final/ontology-dashboard
   

3. Ask Codex to inspect or edit files in the workspace.

4. Observe that the workspace root may be stat-able, but child paths fail with Operation not permitted.

5. In the same environment, reselect or reattach the workspace folder in the Codex Desktop UI.

6. Observe that access may immediately recover and the same commands can read/edit files again.

Minimal diagnostic commands used:

/bin/ls -ldeO@ /Users/<user>/Documents/final/ontology-dashboard
/bin/ls -leO@ /Users/<user>/Documents/final/ontology-dashboard/scripts
/usr/bin/xattr -l /Users/<user>/Documents/final/ontology-dashboard

A second folder under ~/Documents showed the same pattern:

/bin/ls -ldeO@ /Users/<user>/Documents/portfolio
/bin/ls -leO@ /Users/<user>/Documents/portfolio

What is the expected behavior?

If a local workspace folder is selected/attached in Codex Desktop and appears in the effective workspace context, Codex should retain stable read/write access to that workspace's child paths for the running session.

If macOS TCC/sandbox access is missing or stale, Codex should surface a clear diagnostic telling the user to reauthorize or reselect the folder, instead of failing as if the project files themselves were not readable.

Additional information

This does not appear to be caused by project file permissions, Git state, Docker, or dependency cleanup.

Relevant observations:

• The affected folders were owned by the current macOS user.
• The workspace root could be stat-ed.
• Child path reads failed with Operation not permitted.
• Reattaching/reselecting the folder restored access for one affected workspace.
• The issue occurred in more than one local project under ~/Documents.
• No chown, xattr -cr, chflags, or move/delete operation was performed on the affected portfolio/final/Codex project directories.
• A separate cleanup task had searched for node_modules/.venv under ~/Documents and removed explicitly listed dependency/cache paths, but it did not delete or move the affected project roots.
• One chmod -R u+w operation was performed only on /Users/<user>/Downloads/sec05, not under ~/Documents.

codex doctor --json summary:

• Codex CLI: 0.151.0

• Desktop app installed and running: 26.825.41651

• Runtime: macos-aarch64

• Sandbox helpers: filesystem sandbox restricted, approval policy OnRequest

• Desktop security assessment: warning, unavailable

• The doctor command itself also printed:

  WARNING: proceeding, even though we could not create PATH aliases: Operation not permitted (os error 1)
  

Possibly related prior issue:

https://github.com/openai/codex/issues/35260

That issue is about secondary folders not being propagated to workspace_roots/writable permissions. This report is slightly different: the folder appears to be the active workspace, but effective macOS filesystem access to child paths can still be lost until the folder is reselected.

Start by reproducing the failure in Codex Desktop with a workspace under ~/Documents, then run the listed /bin/ls, /usr/bin/xattr, and codex doctor --json diagnostics. Compare the active workspace behavior before and after reselecting the folder, and review the related workspace_roots issue #35260. Done means access remains stable or the app provides a clear reauthorization diagnostic.