Incorrect tool provisioning across Codex sessions: missing shell/filesystem-read tools prevents local file access

Resolved 💬 3 comments Opened Mar 9, 2026 by sebastianrosado Closed Mar 12, 2026

What version of Codex CLI is running?

codex-cli 0.112.0

What subscription do you have?

Team

Which model were you using?

gpt-5.3-codex, gpt-5.4

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty (TERM_PROGRAM=ghostty, TERM=xterm-ghostty)

What issue are you seeing?

From one moment to another (and without changing my codex config beyond updating to 0.112.0 and trying out gpt-5.4), in all my Codex sessions, the tool interface appears to be provisioned without shell/filesystem-read capability, so the assistant cannot read local files from paths like file:///Users/... or repo-relative paths (for example api/content_rl_service/rl_loop.py), even though workspace/cwd is visible.

In the affected session, the assistant reported only seeing:

  • web.run
  • apply_patch
  • multi_tool_use.parallel

It explicitly reported not having a terminal command runner (bash/shell/exec) or a direct file-read tool, and therefore could not inspect local files unless content was pasted manually.

What steps can reproduce the bug?

  1. Start a Codex CLI session from a local project directory.
  2. Ask the assistant to open/read a local file via file:///... path or repo-relative path.
  3. In affected sessions, the assistant reports it cannot read local files due to missing shell/filesystem-read tools.
  4. Start another session with the same workflow; behavior may differ (some sessions can read local files, others cannot).

What is the expected behavior?

Sessions launched the same way should have consistent tool provisioning for local development workflows, including filesystem read (and shell where expected).
If tool access is intentionally restricted, the CLI should clearly indicate that at session start and provide actionable guidance.

Additional information

config.toml (beyond model migration at the bottom, has not changed)

#:schema https://developers.openai.com/codex/config-schema.json

# =========================
# Core model configuration
# =========================

model = "gpt-5.3-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000

# Leave room for native compaction near the 272–273k context window.
# Formula: 273000 - (tool_output_token_limit + 15000)
# With tool_output_token_limit=25000 ⇒ 273000 - (25000 + 15000) = 233000
model_auto_compact_token_limit = 233000

# =========================
# Default execution policy (TOP-LEVEL, not under [features])
# =========================
approval_policy = "never"
sandbox_mode = "workspace-write"
web_search = "cached"
personality = "pragmatic"

# =========================
# Feature flags
# =========================

[features]
undo = false
unified_exec = true
apply_patch_freeform = true
shell_snapshot = true
realtime_conversation = false
voice_transcription = false

# =========================
# SANDBOX CONFIGURATION
# =========================
# This explicitly allows network access (SSH, curl, AWS CLI) whenever
# the 'workspace-write' sandbox is active.
[sandbox_workspace_write]
network_access = true

# =========================
# TRUSTED PROJECTS
# =========================
[projects."/Users/[xxxxx]"]
trust_level = "trusted"

[notice.model_migrations]
"gpt-5.2-codex" = "gpt-5.3-codex"
"gpt-5.3-codex" = "gpt-5.4"

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗