codex - 💡(How to fix) Fix Repeated Codex CLI startup appears to trigger large token usage without submitted task prompts [1 comments, 2 participants]

What version of Codex CLI is running?

codex-cli 0.125.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4-mini reasoning effort: medium summaries: auto

What platform is your computer?

Linux 6.17.0-22-generic x86_64 x86_64

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

Alacritty

What issue are you seeing?

I noticed unusually high Codex usage immediately after starting Codex CLI.

After noticing the usage burn, I started several Codex CLI sessions to verify whether startup itself was correlated with the token usage. I did not submit meaningful task prompts in these sessions.

The local rollout logs show repeated token_count events shortly after startup. Most of the usage is input tokens, with relatively little output or reasoning output.

Captured rollout token_count examples:

14:07:55 UTC

total_tokens: 21,340 input_tokens: 21,027 cached_input_tokens: 4,480 output_tokens: 313 reasoning_output_tokens: 107

14:08:19 UTC

total_tokens: 147,903 input_tokens: 145,809 cached_input_tokens: 112,512 output_tokens: 2,094 reasoning_output_tokens: 710

14:14:08 UTC

total_tokens: 560,192 input_tokens: 555,732 cached_input_tokens: 406,144 output_tokens: 4,460 reasoning_output_tokens: 1,246

During the same captured period, the 5h usage indicator increased from 47% to 66%, and weekly usage increased from 7% to 10%.

This looks like repeated large startup/context payloads rather than normal task execution.

Memory loading or memory consolidation looks like the most likely contributor from the local logs, because Codex executed commands against the local memory files during the relevant turn.

Relevant thread id:

019dd476-0444-7530-a178-f3f823f73bf6

What steps can reproduce the bug?

1. Use Codex CLI with a configuration similar to the one below.
2. Start Codex CLI from the terminal.
3. Do not submit a meaningful task prompt.
4. Exit and start Codex CLI again several times to verify whether startup is correlated with usage burn.
5. Inspect <HOME>/.codex/sessions/**/rollout-*.jsonl for token_count events.
6. Observe repeated large input token usage shortly after startup.

Relevant config at the time of the incident, with sensitive values redacted:

model = "gpt-5.4-mini" model_reasoning_effort = "medium" approvals_reviewer = "guardian_subagent"

[features] memories = true

[mcp] remote_mcp_client_enabled = true

Other context at the time:

Supabase remote MCP configured GitHub curated plugin enabled Multiple MCP servers configured Multiple trusted project entries configured

The UI showed MCP server failures, so I do not know whether MCP contributed to the token usage. The logs still show MCP initialization:

session_init.mcp_manager_init enabled_mcp_server_count=5

Some MCP server startup messages also appear in the logs:

Makerkit MCP Server running on stdio Context7 Documentation MCP Server v2.2.1 running on stdio Google Search Console MCP Server running on stdio

The strongest local signal is memory access. The logs show memory-related tool calls during the relevant turn:

rtk rg ... <HOME>/.codex/memories/MEMORY.md <HOME>/.codex/memories/memory_summary.md

rtk sed -n '1,220p' <HOME>/.codex/memories/memory_summary.md

rtk sed -n '1,120p' <HOME>/.codex/memories/MEMORY.md

rtk git diff --stat -- <HOME>/.codex/memories/MEMORY.md <HOME>/.codex/memories/memory_summary.md

There are also repeated plugin manifest warnings:

ignoring interface.defaultPrompt: prompt must be at most 128 characters ignoring interface.defaultPrompt: maximum of 3 prompts is supported

The relevant log operation is classified as:

codex.op="user_input"

I am not sure why it is classified that way. I did not submit meaningful task prompts. I was starting and restarting sessions to verify the startup-related usage burn.

What is the expected behavior?

Starting Codex CLI without submitting a task prompt should not repeatedly generate large model requests or rapidly increase the 5h and weekly usage counters.

If startup requires model calls for initialization, memory loading, MCP initialization, plugin loading, or session setup, the usage should be small and clearly attributable in the logs.

Additional information

I initially noticed the token burn after startup, then started multiple sessions to verify whether startup was correlated with the usage increase.

The unexpected part is the size and repetition of input token usage. The rollout logs show repeated requests with roughly 21k to 43k input tokens and minimal output. Across the captured period, total token usage increased from 21,340 to 560,192 tokens.

Memory loading looks like the strongest local signal because Codex executed commands against:

<HOME>/.codex/memories/MEMORY.md <HOME>/.codex/memories/memory_summary.md

MCP may or may not be related. The UI showed MCP server failures, but the logs still show MCP initialization with enabled_mcp_server_count=5 and some MCP startup messages.