Desktop: full-CDP silently disabled when CODEX_HOME is a symlink #35310

Summary

Codex Desktop's Browser Developer Mode can show Enable full CDP access as enabled while silently omitting the cdp tab capability from both Browser backends when CODEX_HOME (~/.codex) is a symlink.

The trusted Browser runtime does receive the privileged nodeRepl.config bridge. However, its call to readToml("browser/config.toml") rejects with:

Codex TOML directory must not be a symlink

The Browser client catches that exception, replaces it with a generic internal disabled result, and omits the cdp capability. The settings UI continues to display the toggle as enabled because it reads the same config through a different path that succeeds.

Environment

• Codex Desktop: 26.715.71837 (CFBundleVersion 5702)
• Bundle ID: com.openai.codex
• Bundled CLI: codex-cli 0.145.0-alpha.30
• Platform: Darwin 25.3.0 arm64 arm / macOS 26.3 (25D125)
• Browser bundled plugin: 26.715.71837
• codex features list reports both in_app_browser and browser_use_full_cdp_access as stable/true

Reproduction

1. Use a symlink for CODEX_HOME. In this reproduction:

   ~/.codex -> ~/.dotfiles/codex/codex.symlink
   

2. In Codex Settings → Browser, enable Developer Mode / Enable full CDP access.

3. Confirm ~/.codex/browser/config.toml contains:

   full_cdp_access_enabled = true

4. Restart/reinitialize Browser Use and inspect the capabilities returned by agent.browsers.list().

Actual behavior

Both healthy, connected backends omit the tab-level cdp capability:

• Chrome (extension): browser capability viewport; tab capability pageAssets only.
• Codex In-app Browser (iab): browser capabilities visibility, viewport; tab capability pageAssets only.

The settings UI still shows full CDP access as enabled. No actionable error is shown, and codex doctor does not identify the rejected configuration.

Expected behavior

• A symlinked CODEX_HOME should work, provided the resolved path remains within the intended user-controlled configuration directory and passes appropriate ownership/permission validation.
• If symlinks truly cannot be supported safely, the settings UI should refuse the change or show a clear diagnostic instead of displaying an enabled state that the Browser runtime will silently reject.
• codex doctor should report this configuration/runtime mismatch and include the underlying rejection reason.

Live diagnosis

I attached a temporary in-process debugger to the active Node REPL runtime and set breakpoints inside the trusted, hash-approved bundled Browser client.

The full-CDP gate calls these privileged methods in parallel:

nodeRepl.config.readToml("browser/config.toml")
nodeRepl.config.readRequirements()

Observed results:

[
  {
    "status": "rejected",
    "reason": {
      "name": "Error",
      "message": "Codex TOML directory must not be a symlink"
    }
  },
  {
    "status": "fulfilled",
    "value": {
      "requirements": null
    }
  }
]

This establishes that:

1. The privileged bridge is present in trusted Browser code.

2. Enterprise requirements are not disabling the feature.

3. The TOML read fails specifically because ~/.codex is a symlink.

4. The Browser client catches the exception and returns:

   Full CDP access could not be verified from browser config and enterprise policy.
   

5. Capability enrichment consequently omits cdp.

The public/model-facing globalThis.nodeRepl intentionally lacks config, so checking globalThis.nodeRepl?.config from ordinary submitted code is not a valid test for whether the trusted privileged bridge exists.

UX and diagnostic problems

• The UI reports the persisted setting, not whether the runtime can actually use it.
• The actionable native error is swallowed and replaced with a generic disabled state.
• A normal developer configuration layout is rejected without documentation or a diagnostic.
• There is no codex doctor check for a symlinked CODEX_HOME or for an enabled-but-unavailable full-CDP capability.

Relevant evidence

The exact symlink rejection string is present in the shipped native node_repl executable. I could not find that implementation or either exact error string in the public openai/codex source tree.

Related issues

• Codex Desktop Browser Use ignores persisted origin/upload approvals when nodeRepl.config is unavailable #24017 reports persisted Browser approvals being ignored and inferred that nodeRepl.config was missing.
• Browser Use rejects all external URLs as enterprise network policy when privileged config bridge is missing #30947 reports Browser policy failures and similarly inferred that the privileged bridge was missing.

Those issues may have different platform-specific causes. This report does not claim the symlink rejection explains either one, but the restricted-versus-privileged nodeRepl distinction and swallowed readToml exception may provide a deeper diagnostic path.