Outdated managed Codex runtime misses 6.1 Sol metadata and inflates startup context #27939

Activity

1. Luka-Bazooka

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 31, 2026
2. Luka-Bazooka commented on Oct 31, 2026

   

   Luka-Bazooka

   on Oct 31, 2026

   Last edited by Luka-Bazooka

   Author

   More actions

   Historical same-build model comparison, before the runtime upgrade. The confirmed cause and resolution are now summarized in the issue body.

   Historical investigation details (original comment)

   Retested on 0.1.6-nightly.20261031.3956, with app integrations enabled (the diagnostic features.apps=false override has been removed).

   Fresh conversations sending the identical prompt hi report:

   Model	First-request input tokens	Reported context window
   gpt-6-sol	21,279	258,400
   gpt-6.1-sol	218,396	258,400

   Both results come from the same T3 build and the same provider-process log. These are the first thread/tokenUsage/updated snapshots for their respective fresh conversations, not cumulative usage after multiple requests.

   The gpt-6.1-sol turn also emits:

   Model metadata for `gpt-6.1-sol` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
   

   This confirms the problem persists on the newer nightly and establishes a model-dependent difference. The metadata fallback is a diagnostic clue; its causal relationship to the inflated context is not yet proven. The user needs to retain all tool access.

   Prepared by Codex (GPT-6) from local provider logs, posted at the reporter's request.
3. Luka-Bazooka commented on Oct 31, 2026

   

   Luka-Bazooka

   on Oct 31, 2026

   Last edited by Luka-Bazooka

   Author

   More actions

   Supporting catalog-request and runtime-upgrade evidence. The issue body contains the concise current findings; full verification details are retained below.

   Historical investigation details (original comment)

   Confirmed the catalog filtering and verified a tool-preserving resolution on the affected Windows installation.

   Live catalog response depends on the Codex client version

   Replayed the catalog GET configured by T3's managed openai_token_sharing provider, using its existing managed authentication helper. The endpoint and credentials were held constant; only the client_version query parameter changed. These were direct diagnostic replays, not an interception of an in-flight T3 request. Every response was HTTP 200.

   Request to https://api.openai.com/v1/models	Models returned	gpt-6.1-sol metadata
   client_version=0.156.1 (T3's pinned runtime)	8	Missing
   client_version=0.158.0	8	Missing
   client_version=0.159.0	10	Present
   client_version=0.160.0	10	Present
   client_version=0.163.0	10	Present
   Parameter omitted	10	Present

   The returned 6.1 Sol metadata includes context_window: 500000, tool_mode: "code_mode_only", and use_responses_lite: true. The tested version boundary lies between 0.158.0 and 0.159.0; the response does not explain the server-side policy behind that cutoff.

   T3's installed runtime source hardcodes Codex 0.156.1. Its separate model manifest offers 6.1 Sol with minVersion: "0.153.0". This lets the model be selected even though the pinned client's catalog response omits its metadata. Source inspection of Codex 0.156.1 confirms that missing metadata has no tool_mode; with the observed feature configuration, that resolves to direct tool exposure instead of Code Mode.

   Runtime upgrade, without a static catalog or disabling tools

   Installed the official codex-package-x86_64-pc-windows-msvc.tar.gz for Codex 0.166.0, verified against the release asset's SHA-256:

   d559bb88e74d471265857b93b7f19bc250dae527673b9191b33534478093f6bc
   

   Installed it beside the old runtime and changed T3's managed active-runtime selection to 0.166.0. The 0.156.1 directory remains available for rollback. No T3 application source was patched. The shared Codex configuration was unchanged during the upgrade: no model_catalog_json override and no features.apps=false setting.

   T3 picked up the new runtime without a full desktop restart. The actual in-app provider initialization reports:

   T3 Code/0.166.0 ... (T3 Code; 0.1.6-nightly.20261031.3956)
   

   Successful in-app reproduction check

   Created a fresh scratch chat in T3, selected gpt-6.1-sol, and sent the same minimal prompt, hi.

   First model request	Before, Codex 0.156.1	After, Codex 0.166.0
   Input tokens	218,396	26,752
   Output tokens	47	14
   Reported usable context window	258,400	475,000
   Missing-model-metadata warning	Present	Absent

   The upgraded turn completed successfully, and the response was visible in the actual T3 conversation: Hi! What would you like to work on? The UI showed approximately 94% context remaining.

   Tool settings were not changed. An inventory probe using the same 0.166.0 executable (binary hashes matched) still exposed 383 codex_apps connector tools, plus 3 cua_repl tools and 4 node_repl tools. That inventory probe was a separate managed-auth process, not the in-app thread; T3 added its normal MCP setup to the actual in-app test. This confirms inventory availability and successful startup, not end-to-end execution of every third-party connector.

   The successful in-app result uses live model discovery, not the earlier diagnostic static-catalog workaround.

   Related upstream work

   • feat(providers): managed Antigravity and Codex installs can update past their pin #21249 remains open to allow T3-managed runtimes to update beyond their pinned release.
   • [Bug]: Reasoning effort selector missing for built-in GPT-6.1 Sol on managed ChatGPT provider; Astra works #26707 and fix(codex): preserve reasoning controls for account-only models #27790 describe missing reasoning controls for account-catalog models without matching native Codex metadata; the outdated managed runtime is relevant to that discovery mismatch too.
   • The installed T3 compatibility manifest marks Codex >=0.156.0 supported and recommends >=0.159.0. No explicit block on 0.166.0 was found.

   Raw authentication output, headers, home paths, account identifiers, and full catalogs are omitted.

   Prepared by Codex (GPT-6) from local source inspection, live catalog replays, and in-app verification. Posted at the reporter's request.
4. Luka-Bazooka

   changed the title [-]Fresh managed Codex chats consume about 218k context tokens with app connectors enabled[/-] [+]Outdated managed Codex runtime misses 6.1 Sol metadata and inflates startup context[/+] on Oct 31, 2026
5. ai-scott commented on Oct 31, 2026

   

   ai-scott

   on Oct 31, 2026

   More actions

   Seeing the same thing on macOS (T3 Code 0.1.3 desktop), with a different failure on the catalog path, plus a workaround that has held for a day.

   Environment: T3's managed runtime is npm @openai/codex 0.163.0, provider openai_token_sharing, model gpt-6.1-sol. The Codex desktop app (bundled CLI 0.164–0.166) also runs on this machine.

   What differs from the Windows report:

   • Here the runtime is already 0.163.0, above the 0.159.0 catalog cutoff you found, yet we still get Model metadata for gpt-6.1-sol not found ... fallback metadata.
   • The runtime's catalog refresh from /v1/models returned 401 for us, not 200 with a filtered list.
   • It then rejected the shared ~/.codex/models_cache.json with models cache: cache version mismatch. The Codex desktop app on the same machine rewrites that cache with its own client_version every few minutes, so T3's runtime never gets a usable cache.

   Impact: delegated Codex children started at roughly 170k–258k of a 258k window before reading anything. They compacted after a single file read and looped for hours. Across 104 sessions from 2026-10-25 to 10-30, the first turn_context split exactly:

   • multi_agent_version: "v2" with a service_tier: healthy, about 17–22k first-turn tokens;
   • "disabled" with no tier: bloated.

   Workaround (stable since 2026-10-30): pin the catalog in ~/.codex/config.toml:

   model_catalog_json = "~/.codex/model-catalog.json"   # absolute path in practice

   The file holds a copy of a valid catalog's models list. Then restart T3's Codex runtime: a running app-server loads the models manager only once, at startup. On the same binary with T3's launch flags, the first turn dropped from 170,774 tokens without the pin to 17,486 with it, all MCP servers enabled. A T3 child verified afterwards started at 19,771 tokens, peaked at 44,762 and never compacted.

   Suggestion: besides bumping the managed runtime pin, it would help if T3:

   • shipped or injected model metadata for every model it offers, through model_catalog_json or equivalent, so the runtime doesn't depend on the /v1/models refresh or on a shared cache another Codex install can overwrite;
   • warned in the UI when a session starts on fallback metadata.
6. shuaces commented on Oct 31, 2026

   

   shuaces

   on Oct 31, 2026

   More actions

   Same issue on two more Windows machines (nightly 0.1.6-nightly.20261031.3956, managed ChatGPT-sharing provider, pinned runtime 0.156.1). Two things that may help:

   Impact on delegated agents. Every gpt-6.1-sol session on the pinned runtime started at 308–322k input tokens against the reported 258,400 window (11 of 11 sessions over 5 days). Each request therefore overflows before the agent does anything. The agent compacts after every tool call, loses the files it just read, and reads them again. One session compacted 57 times; a read-only test ran the same file read 5 times and never answered. On the same machine, gpt-6-astra/gpt-6-luna start at 24–27k on the same runtime, and gpt-6.1-sol on Codex Desktop 0.165 starts at 30–55k with a 475k window.

   A workaround that needs no catalog file. Install the current CLI (npm i -g @openai/codex@0.166.0). Then, on the provider instance in settings.json, set "config": { "setupMode": "existing", "binaryPath": "<npm root -g>/@openai/codex/node_modules/@openai/codex-win32-x64/vendor/x86_64-pc-windows-msvc/bin/codex.exe" }. Saving the setting doesn't restart an app-server that's already running. Stop the old ...\.t3\tools\codex\0.156.1\bin\codex.exe app-server process, or restart T3, and the next turn uses the new binary. Result on both machines: first request 30.6k / 30.7k of a 475,000 window, no compaction, correct answer.

   setupMode is hidden in the settings form, so a user hitting this can't find the workaround from the UI.
7. ethanjnrg commented on Nov 1, 2026

   

   ethanjnrg

   on Nov 1, 2026 – with ChatGPT Codex Connector

   More actions

   Adding a related missing-control observation at the user's request (Windows, November 1, 2026): the user cannot find Fast mode for Codex models in T3 Code. In this session, T3's orchestrator_capabilities response advertises only reasoningEffort for the Codex models, including gpt-6.1-sol; there is no advertised serviceTier option. The same response does advertise fastMode for Claude Opus 5.5.

   This is not a reproduction of the startup-context problem, and we have not established that the missing Fast/service-tier control shares this issue's root cause. No runtime-version check, raw upstream capability capture, or service-tier request verification was performed in this investigation. Please consider checking whether service-tier capability discovery is affected by the runtime/catalog mismatch, or point us to the appropriate separate issue if it is unrelated.

   Posted by Codex on behalf of the user.