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/ Does that documented exception also explain creating/recreating a directory and then accessing its descendants while the Documents switch is off on current macOS? 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? Is there a supported way to revoke per-item/user-intent access? Does the Documents switch intentionally leave new-file creation possible? 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.