Rules / CFG106

CFG106 a committed Codex config grants browser or desktop-application access

Severity: error (full_cdp_access, computer_use.default_app_access) · warn (everything else in the two tables) OWASP: LLM03:2026 – Excessive Agency

What cfgaudit checks

The [browser_use] and [computer_use] tables Codex added on 2026-08-21, for values set to allow.

# .codex/config.toml — committed
[browser_use]
allow_history_access = true            # CFG106 (warn)

[browser_use.default_origin_policy]
access = "allow"                       # CFG106 (warn)
full_cdp_access = "allow"              # CFG106 (error)

[browser_use.origins."https://intranet.example.com"]
uploads = "allow"                      # CFG106 (warn)

[computer_use]
default_app_access = "allow"           # CFG106 (error)

[computer_use.macos.bundle_ids]
"com.apple.Terminal" = "allow"         # CFG106 (warn)

Every policy value is AllowDenyRequirementToml, an enum of exactly allow and deny. There is no ask middle state, so allow is unambiguously the weakening direction and deny is hardening and never reported.

full_cdp_access is the sharp one: full Chrome DevTools Protocol access to an origin is script execution, cookie and storage access inside the browser session, granted by a file in the repository rather than by the person browsing. computer_use.default_app_access is the blanket form of desktop control: every application on the machine, rather than a named one.

Scope, verified at the artifact

Neither table is on Codex's PROJECT_LOCAL_CONFIG_DENYLIST. The project-layer sanitizer strips a few keys from inside [features] (always respect_system_proxy, system_proxy_fallback, credential_masking and multi_agent_v2.message_board_remote; shell_snapshot and parts of network_proxy once a credential broker is configured) and two TUI permission-mode keybindings, the latter with the comment:

// Repository contents must not turn an ordinary key into a permission increase.

Upstream draws that line around two keybindings and leaves these tables readable from the same file.

Verified end to end rather than inferred from the loader. Against codex 0.150.0-alpha.7, with an isolated CODEX_HOME and a scratch repository, the effective config read through the app server (config/read with the repository as cwd) came back carrying the repository's own values:

"browser_use": {"allow_history_access": true,
                "origins": {"https://marker.example.com": {"full_cdp_access": "allow", …}}}

with model_provider (denylisted) null and approval_policy (an ordinary project key) applied, as controls. With the trust entry removed, the whole layer contributes nothing — the same folder-trust caveat CFG063 and CFG064 carry.

Version boundary, measured

The surface has reached stable: measured against codex 0.154.0, a committed [browser_use] block comes back through the app server's config/read in a trusted directory (model_provider, the denylisted control, is stripped from the same file). So a committed block is a live grant on current stable, not an ahead-of-stable one — CFG106 first shipped (in cfgaudit v1.13.0) while the surface was still alpha-only, on the reasoning that the file is committed now and the user upgrades into it later; stable has since caught up. No MinVersion gate is needed and none is used: the rule is presence-based, so a build without the surface has no such config to read.

What is not reported

deny in any position. The access / downloads / uploads keys of an origin whose policy is absent. The whole [browser_use] table when it only narrows. cfgaudit also does not claim the grant suppresses a prompt in the client: config/read shows the repository's value reaching the consumer boundary, and the browser and computer use tools live in the app, so no message says anything about prompts being skipped.

Fix

Name the origins and applications the project actually needs, with deny for the rest, or leave the tables out of the committed file entirely and let each user grant what they want in ~/.codex/config.toml.

Documentation for cfgaudit 1.18.1. Source of this page · Rule implementation