Repository navigation
[Linux][In-app Browser] "admin-enforced policy could not be verified" is caused by ChatGPT project folder swap deleting node_repl's working directory #50143
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.31416 (build 12553), prod channel; bundled CLI 0.159.2
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Linux 7.0.0-34-generic x86_64 unknown (Ubuntu 26.04.1, X11)
What issue are you seeing?
Every in-app browser action fails on every origin (example.com, Wikipedia, IANA, YouTube, Google Drive/Vids) with:
Browser Use could not complete this action because a browser security check was unavailable. Reason: The admin-enforced policy could not be verified, so access was not granted.
There is no admin policy. configRequirements/read returns null for allowBrowserAndComputerUse, browserUse, inAppBrowser, computerUse, network and featureRequirements, and config.browser_use is null.
Root cause (reproduced):
- Chats inside a ChatGPT project run with cwd
~/.codex/.chatgpt-projects/g-p-<id>, and each chat'snode_replMCP host inherits that cwd. - The project-file sync (
app.asar,async function DC({downloadFile,files,...})) replaces the folder: it builds.<name>-staging-<uuid>, runsrename(root, .<name>-previous-<uuid>)andrename(staging, root), then deletes the previous folder. - Every running
node_replis left with a deleted cwd:readlink /proc/<pid>/cwd→.../.g-p-<id>-previous-<uuid> (deleted). - For the origin policy check,
browser-service.mjscallsnodeRepl.config.readRequirements()andnodeRepl.config.read({cwd, includeLayers:false}).node_replserves these by spawningcodex app-server(CODEX_CLI_PATH), which inherits the deleted cwd and exits immediately withError: No such file or directory (os error 2). hQ()inbrowser-service.mjs(try{...readRequirements(),readAll()...}catch{return "unavailable"}) maps that transport failure toenterprise_policy_unavailable, which surfaces as the misleading "admin-enforced policy" message.
Creating a new chat in the project triggers the swap itself, so a new chat is broken from its first browser call. Restarting the app only helps until the next swap. Rebinding the browser UI or reopening the chat does not help, because the same node_repl host is reused.
What steps can reproduce the bug?
- On Linux, open a chat inside a ChatGPT project and use the in-app browser on example.com. It works.
- Create another chat in the same project.
readlink /proc/$(pgrep -x node_repl | head -1)/cwdnow ends in.g-p-<id>-previous-<uuid> (deleted).- Use the in-app browser in either chat. Every origin fails with the error above.
Standalone confirmation:
cd /proc/<node_repl pid>/cwd && /usr/lib/chatgpt/resources/codex app-server
# Error: No such file or directory (os error 2) (exit 1)
From a valid directory, the same binary answers initialize, configRequirements/read and config/read successfully.
Observed timeline (2026-10-02, UTC+8), with a watcher sampling node_repl cwd every 2 s:
| Time | Event |
|---|---|
| 09:24 | App fully quit; no Codex processes |
| 09:26–09:32 | App reopened; all node_repl hosts have a valid cwd |
| 09:32:25 | New chat created in the project (thread/start); its node_repl starts |
| 09:32:28 | Project folder replaced; all 4 running node_repl hosts switch to a deleted cwd in the same sample |
| 09:32–09:33 | In-app browser test and retry both fail with the policy error |
The same pattern occurred earlier: the browser worked at 00:45–00:46, the folder was swapped at 00:46:18, and everything failed afterwards.
What is the expected behavior?
- Browser Use should work regardless of project-folder resyncs.
- A failure to reach the policy source should not be reported as an administrator policy.
Additional information
Suggested fixes:
- Update the ChatGPT project folder in place, or keep a stable directory, instead of renaming and deleting a directory that running hosts use as their cwd.
- Spawn
codex app-serverfromnode_replwith an explicit existingcurrent_dir(e.g.CODEX_HOME). Cwd-dependent config is already passed via thecwdparameter. - In
browser-service.mjs, distinguish "policy source unreachable" from "admin policy" and surface the underlying error (e.g. "could not start codex app-server: No such file or directory").
Platform: Confirmed on Linux. macOS has the same POSIX deleted-cwd semantics, so it is probably affected (not tested). Windows normally refuses to rename a directory that is in use as a cwd, so it may differ.
Possibly related (same symptom, cause not identified there): #42466, #46295, #49301, #46350, #49270. Other reports may have different triggers, but any exception in the config bridge produces this same message.
No security settings, policies, credentials or app files were modified during diagnosis.
Activity
github-actions commentedon Oct 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
1seal commentedon Oct 4, 2026
Additional controlled macOS evidence for this report; the original browser incident is not yet causally bound to it.
Environment: Codex desktop 26.930.31730 (build 12947, prod); the configured updater reports no eligible update. A separate official standalone CLI is 0.160.0. The experiment was performed with both that CLI and the app's shipped CLI launcher.
For each executable, three newly spawned, bounded
app-server --listen stdio://processes used the same existing explicitconfig/read.cwd. Only their inherited process working directory differed:initialize,configRequirements/readandconfig/readreturnNo such file or directoryThis reproduces a config-transport failure on macOS despite a valid explicit config context. It does not establish that every unavailable browser-policy check has this cause. We could not identify the original failing browser host with sufficient confidence, so its diagnosis and recovery remain unverified. No browser retry, security-setting change or existing-host restart was used for this experiment. All six diagnostic process groups ended.
Could maintainers provide a supported way to correlate an unavailable browser-policy check with its host/config-subprocess error, and recover only that failed host after the cause is fixed? A config transport failure should remain fail-closed while exposing a distinguishable technical error and a supported recovery condition. We also need to know whether a stable process working directory for the config subprocess is the intended fix.
This comment contains no account identifiers, project contents, credentials or raw logs.
nexus-rra commentedon Oct 8, 2026
Additional macOS evidence supporting the deleted-working-directory mechanism described here (read-only diagnostics; causal chain not yet fully confirmed).
Environment: ChatGPT Desktop 26.928.21956 on macOS, bundled Codex CLI 0.159.2. Browser backend explicitly identified as Codex In-app Browser (
iab).Controlled behavior (same computer, backend, and
https://example.com/):Example Domainloaded and was readable.The admin-enforced policy could not be verifiedsecurity-check error.cdpworked, but these are different browser backends and do not constitute aniabfix.Read-only macOS process inspection in the affected project:
node_replPIDs 6851, 6854 and associated Codex processes retained working directories under missing project-previous-e58…/-previous-323…paths.node_replPIDs 8629, 8634 and associated Codex processes retained working directories under missing-previous-57c…/-previous-904…paths.node_replPIDs 8958, 8965 had an existing current-project working directory.codex app-server(PID 8541) had an existing working directory belonging to a standalone, non-project diagnostic.These observations support the same project-folder-replacement / stale
node_replcwd failure mechanism on macOS. We did not capture the failingcodex app-serverspawn or config-policy bridge directly, so root-cause status should be SUPPORTED, not CONFIRMED.No cache deletion, process restart, configuration/security changes, or browser security bypass was performed. The process IDs and shortened suffixes are diagnostic snapshots, not stable identifiers.
Could maintainers advise a safe, supported way to capture the failing app-server/config bridge trace on macOS, and whether a product fix or safe recovery procedure is available? This currently blocks in-app browser execution in project conversations while standalone sessions succeed.