Desktop context indicator shows 317,972 tokens while auto-compaction uses 400,990 (Windows → SSH, CLI 0.153.4)

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.901.51231, released September 5, 2026 (from About Codex).

Remote app-server: codex-cli 0.153.4, verified by executing /proc/<app-server-pid>/exe --version, rather than relying on the CLI on PATH.

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Windows 10 22H2 running Codex Desktop, connected over SSH to a Debian 13 (trixie) LXC container.

Remote uname -mprs:

Linux 7.0.2-6-pve x86_64 unknown

What issue are you seeing?

The context indicator and the automatic-compaction decision report substantially different token counts for the same task at the same sampling boundary. Automatic compaction started while the UI displayed:

Context: 26% left (317,972 used / 428K)

The remote harness had correctly loaded my explicit 400,000-token auto-compaction threshold. Its runtime log recorded 400,990 tokens and triggered compaction, while the rollout token-count event reported 317,972 tokens. The discrepancy is 83,018 tokens.

I initially suspected the configuration was ignored. Logs rule that out. However, they do not establish whether the display omits valid accounting, the compaction counter overcounts, or the two intentionally represent different quantities. Please investigate the accounting contract as well as the display; this is not a request to postpone valid compaction beyond the configured threshold.

Relevant configuration:

model_context_window = 450000
model_auto_compact_token_limit = 400000

Runtime reasoning effort: ultra. Runtime compaction scope: Total.

The local model cache records effective_context_window_percent: 95. The rollout's effective window is 427,500 (= 450,000 × 0.95), consistent with the UI's rounded 428K denominator.

Matching evidence at 2026-09-08 01:47:39 UTC (September 7, 8:47:39 PM CDT):

Rollout event_msg / token_count at 2026-09-08T01:47:39.559Z, reduced to relevant fields:

{
  "last_token_usage": {
    "input_tokens": 317399,
    "cached_input_tokens": 316544,
    "cache_write_input_tokens": 0,
    "output_tokens": 573,
    "reasoning_output_tokens": 505,
    "total_tokens": 317972
  },
  "model_context_window": 427500
}

Runtime codex_core::session::turn log at 2026-09-08 01:47:39 UTC (span prefixes omitted):

post sampling token usage
 total_usage_tokens=400990
 auto_compact_scope_tokens=400990
 auto_compact_scope_limit=Some(400000)
 auto_compact_limit_scope=Total
 auto_compact_window_prefill_tokens=None
 full_context_window_limit=Some(427500)
 full_context_window_limit_reached=false
 token_limit_reached=true
 model_needs_follow_up=true
 has_pending_input=false
 needs_follow_up=true

The preceding runtime check at 01:47:02 UTC recorded:

total_usage_tokens=398834
auto_compact_scope_tokens=398834
auto_compact_scope_limit=Some(400000)
token_limit_reached=false

A compacted record was subsequently persisted at 2026-09-08T01:50:48.413Z. Task sampling continued afterward. There was no compaction failure in this observed incident.

These are not lifetime-versus-current usage numbers: 317,972 is specifically last_token_usage.total_tokens; 400,990 comes from the runtime compaction check, not the rollout's cumulative total_token_usage object.

What steps can reproduce the bug?

Observed workflow; no deterministic minimal reproduction has been established:

1. Connect Windows Codex Desktop to a Linux remote host using SSH.
2. Set the configuration above on the remote host and use GPT-6 Astra.
3. Run a long, tool-heavy task. The affected task used delegated agents and received agent messages; whether this is necessary is unknown.
4. Continue until automatic context compaction starts.
5. Compare the displayed context usage with the same task's latest rollout token_count event and remote post sampling token usage log.
6. In this occurrence, the display and rollout reported 317,972 / 427,500, while the compaction check reported 400,990 / 400,000 and token_limit_reached=true.

Session/task ID: 01a07e5f-9cdc-78c0-925b-f9b3cbc486f6

Turn ID: 01a07e60-f61c-7073-8e88-e6b67bd50133

The task contains private repository work, so the full prompt and raw rollout are omitted. Sanitized accounting evidence is included above.

What is the expected behavior?

The context indicator should explain the context pressure used by automatic compaction. If request-reported usage and the harness's active-context estimate legitimately differ, show or clearly label both and expose the effective compaction threshold.

If the extra tokens are being counted twice, correct the compaction accounting instead of making the display agree with an inflated number. Valid automatic compaction at the configured threshold is welcome; the problem is the unexplained discrepancy that makes it appear the threshold was ignored.

Additional information

Remote process verification:

PID      PPID     command
2657272  2220768  .../0.153.4-x86_64-unknown-linux-musl/bin/codex app-server --remote-control --listen unix://

/proc/2657272/exe resolves to that same versioned binary; executing it with --version returns codex-cli 0.153.4. The process start time was September 4, 2026, 18:46:29 CDT.

Related issues found before drafting:

• https://github.com/openai/codex/issues/40756 — context-percentage baseline arithmetic. This report includes a mismatch in the absolute token counts, not only the percentage.
• https://github.com/openai/codex/issues/38154 — lifetime/current token naming. Here the displayed value matches the last-request counter, so lifetime usage confusion does not explain this incident.

Start at the named codex_core::session::turn runtime path and compare its post-sampling token usage with the rollout event_msg/token_count data. Reproduce the Windows-to-SSH workflow if possible, then determine whether the differing counts are intentional or miscounted and ensure the context indicator and compaction threshold are explained consistently.