Tools are sent to the model even if not configured
What version of Codex CLI is running?
0.98.0
What subscription do you have?
pro
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Linux 6.18.6-arch1-1 x86_64 unknown
What terminal emulator and version are you using (if applicable)?
n/a
What issue are you seeing?
Codex CLI includes tools that are not configured in the list sent to the AI model.
What steps can reproduce the bug?
- Have no MCP servers configured.
- Log the actual network traffic. I had it log to a file based on the session file Codex was already making, but also with
-trafficin the name. Happy to share the patch, but Codex made it for me. Log outbound aroundcodex-rs/codex-api/src/endpoint/responses.rs:137andcodex-rs/codex-api/src/endpoint/responses_websocket.rs:254, and inbound aroundcodex-rs/codex-api/src/sse/responses.rs:372andcodex-rs/codex-api/src/endpoint/responses_websocket.rs:296. - Conduct a session.
- View the logged traffic, and observe the tools array includes
list_mcp_resources,list_mcp_resource_templates,read_mcp_resource.
What is the expected behavior?
If a tool is not configured, it should not be sent to the AI model.
Sending it:
- Unnecessarily burns (a small amount of) tokens.
- Unnecessarily uses (a small amount of) context window, (very slightly) degrading model performance.
Additional information
Surely, more tools will be added in the future. I think getting the policy and code in place now to avoid sending unconfigured tools will have larger future benefits.
Additionally, I think a wider effort could be made to avoid sending unnecessary things to the model, so that parts of internal Codex prompt .md files can be omitted if they are not relevant in the current thread.
Note: In case anyone is looking for why more tokens are charged by the API than the Codex session logs show, the tools information is not currently in the sessions file but those are charged as input tokens.
5 Comments
These are built-in tools similar to
exec_command, etc. See here in the code.Is there an behavioral problem you're seeing, or are you just concerned about token usage? The number of tokens needed to report these tools to the model is very small.
To me, this signal-to-noise ratio and context hygeine issue does stealthily affect some behavior, but certainly not in the sense of an outright demonstratable failure.
There's precedent for fixing this, as Codex CLI practices lazy loading for skills boilerplate. If no skills are configured, it omits the skills boilerplate that is otherwise appended to AGENTS.md. I'm sure not many people have disabled the built-in creator and installer skills, so it seems logical to me that tools should not be advertised if inactive when I think many people don't have MCP servers configured.
It's an 'n-times' token cost. Although about 460 tokens is small, in a 20-turn session, that is about 9,200 tokens. Across the entire Codex user base, that's a large amount of unnecessary global tokens.
I think it's immune to compaction. I could be wrong, but I assume tool definitions are static and immune to compaction. That means these dead-end tool tokens are permanently reducing the available context window. (Yes, in a small amount.)
It's also about model attention. Every added token of boilerplate increases the "distraction surface". As Codex (rightfully) adds more sophisticated boilerplate for planning ang agentic prompts, it feels important to trim the fat where possible to ensure the model's attention stays on relevant information, not unused plumbing.
This feels like low-hanging fruit to me, but no, it isn't causing a concrete behavioral issue, and isn't causing a large stealth behavior effect.
There's a work around that requires creating a separate config toml in a separate dir and pointing bogus skills to a bogus path, you'll get a "cant load skills error" logged but it cleans the context. I had to do this for the exact same reason. It's a waste of money and context pollution, there's really no other work around that I've found and I spent a long time looking for this.
My issue is for trimming the the MCP tools from the tools list when MCP servers aren't configured, which we can't even tell is polluting the input tokens and being sent without doing something like modifying the Codex source and having it make a log of the exact inbound and outbound traffic. The tools list isn't part of the session log, and the API site in logs doesn't show us Codex calls.
I did mention the skills text is omitted if there's no skills, which is what you're talking about. Codex showed me that adding this to config.toml disables the built-ins, and doesn't give the error that your method does:
(Just like this, not single brackets! Of course, use your actual full path.)
The issue was about tools, but since I discussed a way to disable the built-in skills and prevent them from being sent, I wanted to mention that v0.114.0 includes #13792 which allows this in config:
[skills.bundled]
enabled = false
I actually missed that v0.102.0 included #11900 which says it drops MCP managing tools if no MCP servers. I'll have to try that out soon.