Why Codex bypass TCC

[jyxjjj]

I found that Codex.app created a directory named "Codex" in Documents without any TCC prompt. How is that even possible?

I even checked the TCC logs and found no authorization request at all. I also tried removing the MACL attributes, but the app was still able to write to the directory.

Interestingly, if I manually create the "Codex" folder, the app can still write into it without triggering TCC. However, creating other files in Documents does trigger a TCC prompt.

Relates to: #19909 #20880

[hoodrichpirobo]

I would separate two things here:

1. macOS TCC / app entitlements
2. Codex’s own agent sandbox

This does not necessarily mean Codex is bypassing TCC in the exploit sense. The strongest clue is that only this specific path works:

~/Documents/Codex

while arbitrary writes elsewhere in ~/Documents still trigger the normal TCC prompt.

That usually means macOS is allowing this path through some app-specific mechanism, such as an entitlement, sandbox extension, security-scoped bookmark, or temporary/home-relative file exception. In that case there may be no new TCC prompt and no normal TCC authorization log, because the access is being satisfied before the usual “ask the user for Documents access” flow.

Removing com.apple.macl is not necessarily enough to prove there is no grant. MACL is only one artifact. Access could also come from:

- the app’s code-signing entitlements
- a security-scoped bookmark stored by the app
- a sandbox extension
- an existing TCC database decision
- a special home-relative path exception

The useful test is to inspect the app and reset grants:

osascript -e 'id of app "Codex"'
codesign -d --entitlements :- /Applications/Codex.app 2>/dev/null
tccutil reset All <bundle-id>
rm -rf ~/Documents/Codex
open -a Codex

Then test whether Codex can write only here:

~/Documents/Codex

or whether it can also write arbitrary files like:

~/Documents/codex-tcc-test.txt
~/Documents/OtherFolder/test.txt

If only ~/Documents/Codex works, this is probably a path-specific app allowance, not a general Documents-folder bypass.

That said, I agree the behavior is still undesirable. Even if macOS permits it, the app should not silently create a user-visible folder under ~/Documents on launch. Better options would be:

~/Library/Application Support/Codex
~/.codex

or a user-selected/configurable project directory.

Also important: this is separate from the Codex agent sandbox. The app creating its own bookkeeping/project folder is not the same as a Codex agent being allowed to freely edit all of ~/Documents. Agent filesystem access should still be controlled by Codex permissions/sandbox settings. But the app-level ~/Documents/Codex creation should probably be tracked as an app behavior bug / UX issue, as in #19909 and #20880.

[jaypresent]

Adding a related investigation, with the evidence and its limits spelled out. I would appreciate maintainer guidance on which macOS mechanism is expected here and how users can revoke it. This is not a proposed answer or a confirmed bypass.

I'm investigating the boundary between Documents TCC protection and the app-created-file/user-intent exceptions on macOS 27.0.1. This is a request for supported diagnostics and revocation guidance, not a claim of a security bypass. Paths and process labels below are anonymised; the trace summaries describe observations, not a complete reproducer.

Observed behaviour

With Documents access disabled for a ChatGPT/Codex desktop app in Privacy & Security, its direct file tool created a workspace directory under ~/Documents and a new text file inside it. The file and contents were independently verified in Terminal. After the workspace was deleted manually and its absence verified, the tool recreated the directory and another test file without a new consent prompt. Restarting the app did not prevent this. No access to unrelated, pre-existing personal documents has been established.

An fs_usage capture during a successful test showed an open for writing followed by WrData[A] on the test path, attributed to a local process named codex. The numeric suffix in that capture has NOT been conclusively correlated to the executor PID; it should not be treated as proof of the exact process chain.

Process and signing observations

A separate launchctl procinfo inspection of a local Codex exec-server showed sandboxed = no, with the desktop app as its responsible process. This establishes the inspected executor's state, not necessarily the dynamic restrictions of the exact writer or its children.

The desktop bundle identifier is com.openai.codex. The embedded CLI has signing identifier codex and application identifier 2DC432GLL2.com.openai.codex.cli. These are vendor identifiers, not account identifiers.

Embedded entitlement XML was read directly from the Mach-O LC_CODE_SIGNATURE superblob, because codesign diagnostics inside a later restricted tool environment were inconclusive. The desktop executable declares com.apple.security.app-sandbox = false, com.apple.security.files.user-selected.read-write = true and com.apple.security.automation.apple-events = true. The CLI's embedded entitlements include its application/team identifiers and JIT/unsigned-executable-memory permissions, with no app-sandbox entitlement. These are embedded declarations, not a claim that runtime validation or every effective grant has been verified. Being outside App Sandbox does not itself remove TCC protection.

TCC chronology

Earlier, a Python operation attributed to com.openai.codex requested kTCCServiceSystemPolicyDocumentsFolder. Its AUTHREQ_RESULT had authValue=0 and authReason=2. A later log recorded deletion of a Documents TCC record for that app, before the successful Codex write. Thus the earlier Python denial does not establish the decision applicable to the later write.

Filtered TCC logs around the successful write contained app identity information but no matching Documents decision; a sandbox-log search found no relevant entry. Those are search results, not proof that no security check occurred.

Extended attributes and application policy

The parent Documents directory had a 216-byte com.apple.macl; the workspace had a 72-byte com.apple.macl. The parent's attribute remained when the child directory was deleted, and the recreated child acquired an attribute again. The identities represented by those records and their causal role are unknown.

A Codex task configuration separately allowed the workspace as writable. That explains an application-policy allowance, not automatically the macOS authorisation. Filename searches did not identify a definite security-scoped bookmark; that does not rule one out. TCC database queries were inaccessible. No Full Disk Access was granted to inspect them.

Questions

Apple's WWDC19 session 701 explains that creating new documents in protected locations needs no consent, and that apps can access files they created or the user selected:
https://developer.apple.com/videos/play/wwdc2019/701/

1. Does that documented exception also explain creating/recreating a directory and then accessing its descendants while the Documents switch is off on current macOS?
2. What supported read-only diagnostics distinguish app-created-item access, a parent-directory MACL grant, security-scoped bookmarks, dynamic sandbox extensions and TCC responsible-process attribution?
3. Is there a supported way to revoke per-item/user-intent access? Does the Documents switch intentionally leave new-file creation possible?
4. For a user who wants to prohibit all Documents writes while retaining the desktop app, is an independently enforced filesystem sandbox required? How should that boundary be tested across direct file tools, shell children and GUI automation?

I would appreciate guidance before any further disposable-file tests, attribute changes or TCC resets. No general Documents bypass or access beyond the workspace has been demonstrated.