MDM `requirements_toml_base64` fails to resolve `~/` paths in `permissions.filesystem.deny_read`
What version of Codex CLI is running?
codex-cli 0.133.0
What subscription do you have?
ChatGPT Enterprise
Which model were you using?
GPT 5.4 - Issue is model agnostic
What platform is your computer?
Darwin 25.5.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
iTerm2
Codex doctor report
{
"schemaVersion": 1,
"generatedAt": "1779673829s since unix epoch",
"overallStatus": "ok",
"codexVersion": "0.133.0",
"checks": {
"app_server.status": {
"id": "app_server.status",
"category": "app-server",
"status": "ok",
"summary": "background server is not running",
"details": {
"control socket": "/Users/<redacted>/.codex/app-server-control/app-server-control.sock",
"daemon state dir": "/Users/<redacted>/.codex/app-server-daemon",
"mode": "ephemeral",
"pid file": "/Users/<redacted>/.codex/app-server-daemon/app-server.pid (missing)",
"settings": "/Users/<redacted>/.codex/app-server-daemon/settings.json (missing)",
"status": "not running",
"update-loop pid file": "/Users/<redacted>/.codex/app-server-daemon/app-server-updater.pid (missing)"
},
"remediation": null,
"durationMs": 0
},
"auth.credentials": {
"id": "auth.credentials",
"category": "auth",
"status": "ok",
"summary": "auth is configured",
"details": {
"auth file": "/Users/<redacted>/.codex/auth.json",
"auth storage mode": "File",
"stored API key": "false",
"stored ChatGPT tokens": "true",
"stored agent identity": "false",
"stored auth mode": "chatgpt"
},
"remediation": null,
"durationMs": 0
},
"config.load": {
"id": "config.load",
"category": "config",
"status": "ok",
"summary": "config loaded",
"details": {
"CODEX_HOME": "/Users/<redacted>/.codex",
"config.toml": "/Users/<redacted>/.codex/config.toml",
"config.toml parse": "ok",
"cwd": "/Users/<redacted>/code/codex",
"enabled feature flags": "shell_tool, unified_exec, shell_snapshot, terminal_resize_reflow, sqlite, enable_request_compression, multi_agent, apps, tool_suggest, plugins, plugin_hooks, browser_use_external, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server, workspace_dependencies",
"feature flag overrides": "hooks=false, in_app_browser=false, browser_use=false, computer_use=false",
"feature flags enabled": "24",
"log dir": "/Users/<redacted>/.codex/log",
"mcp servers": "0",
"model": "gpt-5.4",
"model provider": "openai",
"sqlite home": "/Users/<redacted>/.codex"
},
"remediation": null,
"durationMs": 0
},
"installation": {
"id": "installation",
"category": "install",
"status": "ok",
"summary": "installation looks consistent",
"details": {
"PATH codex #1": "/opt/homebrew/bin/codex",
"current executable": "/opt/homebrew/bin/codex",
"install context": "brew",
"managed by bun": "false",
"managed by npm": "false",
"managed package root": "not set"
},
"remediation": null,
"durationMs": 6
},
"mcp.config": {
"id": "mcp.config",
"category": "mcp",
"status": "ok",
"summary": "no MCP servers configured",
"details": {},
"remediation": null,
"durationMs": 0
},
"network.env": {
"id": "network.env",
"category": "network",
"status": "ok",
"summary": "network-related environment looks readable",
"details": {
"proxy env vars": "none"
},
"remediation": null,
"durationMs": 0
},
"network.provider_reachability": {
"id": "network.provider_reachability",
"category": "reachability",
"status": "ok",
"summary": "active provider endpoints are reachable over HTTP",
"details": {
"ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 403)",
"reachability mode": "ChatGPT auth"
},
"remediation": null,
"durationMs": 290
},
"network.websocket_reachability": {
"id": "network.websocket_reachability",
"category": "websocket",
"status": "ok",
"summary": "Responses WebSocket handshake succeeded",
"details": {
"DNS": "2 IPv4, 2 IPv6, first IPv6",
"auth mode": "chatgpt",
"connect timeout": "15000 ms",
"endpoint": "wss://chatgpt.com/backend-api/<redacted>",
"handshake result": "HTTP 101 Switching Protocols",
"model provider": "openai",
"models etag present": "true",
"provider name": "OpenAI",
"proxy env vars": "none",
"reasoning header": "false",
"server model present": "false",
"supports websockets": "true",
"wire API": "responses"
},
"remediation": null,
"durationMs": 688
},
"runtime.provenance": {
"id": "runtime.provenance",
"category": "runtime",
"status": "ok",
"summary": "running brew on macos-aarch64",
"details": {
"commit": "unknown",
"current executable": "/opt/homebrew/bin/codex",
"install method": "brew",
"platform": "macos-aarch64",
"version": "0.133.0"
},
"remediation": null,
"durationMs": 0
},
"runtime.search": {
"id": "runtime.search",
"category": "search",
"status": "ok",
"summary": "search is OK (system)",
"details": {
"search command": "rg",
"search command readiness": "ripgrep 15.1.0",
"search provider": "system"
},
"remediation": null,
"durationMs": 55
},
"sandbox.helpers": {
"id": "sandbox.helpers",
"category": "sandbox",
"status": "ok",
"summary": "sandbox configuration is readable",
"details": {
"approval policy": "UnlessTrusted",
"codex-linux-sandbox helper": "none",
"execve wrapper helper": "/Users/<redacted>/.codex/tmp/arg0/codex-arg0NbP16m/codex-execve-wrapper",
"filesystem sandbox": "restricted",
"network sandbox": "restricted"
},
"remediation": null,
"durationMs": 0
},
"state.paths": {
"id": "state.paths",
"category": "state",
"status": "ok",
"summary": "state paths and databases are inspectable",
"details": {
"CODEX_HOME": "/Users/<redacted>/.codex (dir)",
"active rollout files": "123 files, 24182129 total bytes, 196602 average bytes",
"archived rollout files": "0 files, 0 total bytes, 0 average bytes",
"goals DB": "/Users/<redacted>/.codex/goals_1.sqlite (file)",
"goals DB integrity": "ok",
"log DB": "/Users/<redacted>/.codex/logs_2.sqlite (file)",
"log DB integrity": "ok",
"log dir": "/Users/<redacted>/.codex/log (dir)",
"sqlite home": "/Users/<redacted>/.codex (dir)",
"state DB": "/Users/<redacted>/.codex/state_5.sqlite (file)",
"state DB integrity": "ok"
},
"remediation": null,
"durationMs": 184
},
"terminal.env": {
"id": "terminal.env",
"category": "terminal",
"status": "ok",
"summary": "terminal metadata was detected",
"details": {
"COLORFGBG": "15;0",
"COLORTERM": "truecolor",
"TERMINFO_DIRS entry": [
"/Applications/iTerm.app/Contents/Resources/terminfo (dir)",
"/usr/share/terminfo (dir)"
],
"TERM_PROGRAM": "iTerm.app",
"color output": "enabled",
"effective locale": "en_AU.UTF-8",
"stderr is terminal": "true",
"stdin is terminal": "true",
"stdout is terminal": "true",
"terminal": "iTerm2",
"terminal size": "165x44",
"terminal version": "3.6.10"
},
"remediation": null,
"durationMs": 0
},
"updates.status": {
"id": "updates.status",
"category": "updates",
"status": "ok",
"summary": "update configuration is locally consistent",
"details": {
"cached latest version": "0.133.0",
"check for update on startup": "true",
"last checked at": "2026-05-25T01:32:36.401064Z",
"latest version": "0.133.0",
"latest version status": "current version is not older",
"update action": "brew upgrade --cask codex",
"version cache": "/Users/<redacted>/.codex/version.json"
},
"remediation": null,
"durationMs": 76
}
}
}What issue are you seeing?
Tilde (~/) path expansion fails in permissions.filesystem.deny_read entries when delivered via MDM requirements_toml_base64, but works correctly in /etc/codex/requirements.toml.
Example requirements TOML (base64-encoded and deployed via MDM profile under com.openai.codex requirements_toml_base64):
[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws"]When loaded from /etc/codex/requirements.toml, these paths resolve correctly to /Users/$USER/.ssh and /Users/$USER/.aws. When the same TOML is base64-encoded and delivered via MDM managed preferences, deserialization fails because AbsolutePathBuf cannot resolve the ~/ prefix.
Root cause: parse_managed_requirements_base64 in codex-rs/config/src/loader/macos.rs calls toml::from_str::<ConfigRequirementsToml>(...) without first setting an AbsolutePathBufGuard. The FilesystemDenyReadPattern deserializer relies on the thread-local guard to resolve non-absolute paths (including ~/). Without it, paths that aren't already absolute fail with "AbsolutePathBuf deserialized without a base path".
By contrast:
- /etc/codex/requirements.toml sets the guard at mod.rs:556
- Cloud requirements were fixed for this same issue in PR #23729 (merged 2026-05-20)
The MDM requirements path was not updated in that PR.
Workaround: Use absolute paths (e.g. /Users/*/.ssh) in the MDM-delivered requirements, or deploy deny_read rules via /etc/codex/requirements.toml instead.
What steps can reproduce the bug?
- Create a requirements TOML file with a tilde path in deny_read:
[permissions.filesystem]
deny_read = ["~/.ssh"]- Base64-encode it:
base64 -I requirements.toml
- Deploy via MDM profile targeting the com.openai.codex preference domain with key requirements_toml_base64, or simulate locally with:
defaults write com.openai.codex requirements_toml_base64 "$(base64 -i requirements.toml)"
- Launch Codex CLI. The deny_read rule fails to load — ~/.ssh is not enforced.
- For comparison, place the same TOML content at /etc/codex/requirements.toml and restart Codex. The ~/.ssh deny_read rule loads and is enforced correctly.
What is the expected behavior?
Tilde paths (~/) in permissions.filesystem.deny_read entries should resolve to the current user's home directory regardless of whether the requirements TOML is delivered via MDM managed preferences (requirements_toml_base64) or via the filesystem (/etc/codex/requirements.toml). Both delivery mechanisms should produce identical runtime behavior for the same TOML content.
Additional information
This is the same class of bug fixed in PR #23729 (commit 0edcc4b94e) for cloud requirements. That fix added an AbsolutePathBufGuard::new(codex_home) before toml::from_str in the cloud requirements parsing path. The MDM requirements path in codex-rs/config/src/loader/macos.rs:parse_managed_requirements_base64 has the identical omission but was not included in that fix.
The fix is a one-line addition of let _guard = AbsolutePathBufGuard::new(requirements_base_dir); before the toml::from_str call, plus threading codex_home through as the base directory (matching the convention established in #23729 and documented in the comment at mod.rs:364-370).
Have prepared fix in: https://github.com/java-james/codex/tree/fix/mdm-requirements-deny-read-path-resolution if required.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗