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.
8. draconianape commented on Nov 4, 2026

   

   draconianape

   on Nov 4, 2026

   More actions

   The compact-after-every-tool-call loop still happens on Codex 0.166.0, the runtime #30004 moves to. It has a second cause: the managed provider's model list gets wiped about an hour into a Codex process's life. I reproduced this with the real 0.166.0 binary.

   Environment: Windows 11 desktop app against its local server, T3 Code 0.1.7-nightly.20261103.4138, Codex 0.166.0, openai_token_sharing, gpt-6.1-sol. Current main still launches Codex with the same two flags described below.

   Symptom

   A delegated Sol child started with window 258,400 and about 425k input tokens per request. It compacted 5 times in 6 minutes, re-reading the same files, and used about 2.66M tokens before it was stopped. A child in the same Codex process 7 minutes earlier had window 828,400, started at 24,872 tokens and never compacted. The difference was Unknown model gpt-6.1-sol is used. This will use fallback model metadata.

   Cause

   1. T3 launches Codex with refresh_interval_ms=0, so a provider's cached token is only replaced after a 401 that triggers recovery.
   2. /responses recovers by re-running the helper. /models has no such recovery and keeps its own cached token. In the repro, /responses moved to the new token while /models kept sending the expired one.
   3. T3 also sets model_catalog_url, which makes this an explicit provider catalog. For those catalogs, a single 401 from /models clears the list in memory and in models_cache.json, with no bundled fallback (codex-rs/models-manager/src/manager.rs, fetch_and_update_models, rust-v0.166.0). The current Codex main still has this branch.
   4. The background refresh runs every 4:30 (models_refresh_worker.rs), so the first refresh after the token expires wipes the list.
   5. Running sessions continue, but the next new session gets fallback metadata: a 272,000 window at 95% (258,400) and no tool_mode, so every MCP tool is exposed directly. Compaction requests carry no tools, so compacting can't get the next request under the limit, and the loop starts.
   6. The process doesn't recover, because it keeps sending the expired token. In one process, all 8 refreshes still in the log failed, across 31 minutes, until the process ended. A new process works.

   This also explains why it looks random. How long a process lasts depends on how much of the saved token's roughly one-hour life is left when it launches. Observed on this machine:

   Time (UTC)	Event
   13:48:54	T3 renews the token
   13:56:22	Codex process starts
   14:46:05	Last good catalog stamp
   14:50:35	Next refresh (+4:30) gets 401
   15:00:43	Next new session logs Unknown model, and T3 renews the token for it
   15:04:10	Restarted process is healthy for its full 40 minutes

   An earlier occurrence fits too, but its first failed refresh had already been pruned from Codex's log, which keeps 1,000 threadless rows per process. That step is inferred.

   Repro

   Real codex.exe 0.166.0 app-server, T3's flags from CodexManagedRuntime.ts, a temporary CODEX_HOME, fake tokens, and a localhost server standing in for /v1/models and /v1/responses that rejects expired tokens. The token expires while idle, then a new thread starts after the real 4:30 refresh:

   Variant	/models at the refresh	New thread
   T3's flags	401 with the old token, cache emptied	258,400, metadata warning, tools exposed directly
   refresh_interval_ms=1000	200 with the new token	828,400
   Without model_catalog_url	401, list kept	828,400
   With model_catalog_json	never called	828,400

   A faster variant, where /models rejects while /responses works, went red 5 of 5 times. features.api_key_model_discovery made no difference to it. With the fake server reporting 425k per request, 4 turns on fallback metadata produced 3 compactions, against 0 on healthy metadata.

   The harness asserts the window and the warning, using a fake server rather than the real API. I can post it if useful.

   Possible fixes

   These are options, not tested patches, apart from what the table shows:

   • Keep the /models token fresh. A non-zero refresh_interval_ms worked in the repro. The interval would need to fit the broker's 60-second renewal window, or /models could still hit an expired token between refreshes.
   • Drop model_catalog_url. The URL matches what base_url would produce, so a 401 would keep the last good list. There may be a reason it's set that I haven't found.
   • Route /models through a broker. fix(server): renew managed ChatGPT tokens rejected before local expiry #29950's local bridge appears to do this by adding a current token to /models requests. From reading the diff, fix(server): managed Codex renews a ChatGPT token the API reports as expired #29946 doesn't touch this path. I tested neither.
   • Make it visible. Codex sends a warning notification (Model metadata for ... not found) at session start. CodexAdapterV2.ts has no handler for it at the affected tag, so the UI shows nothing. Surfacing it, or restarting the app-server when it appears, would catch this and any similar cause.
   • Codex side. Add 401 recovery to the /models request, or don't treat an expired token as access being revoked.

   Workaround

   Pin the list with model_catalog_json in ~/.codex/config.toml, pointing at a file containing {"models": [...]} copied from a healthy models_cache.json. No /models requests were made in the repro. A real T3 thread on this machine then started at window 828,400 and 21,420 tokens, but it hasn't yet run past a real token expiry.

   The pin affects every Codex client sharing that config, and new models won't appear until the file is updated. It also makes T3's status probe wait out its 3-second catalog refresh timeout, because models_cache.json stops being rewritten. Restarting T3's codex.exe also clears the problem, for about an hour.

   Related: #25891 (same symptom), #29927 and #29946/#29950 (token expiry on /responses).

   ---

   Investigated and written by Claude Code (Claude Opus 5.5) during a t3 triage session, at the reporter's request.
9. jappelbaum20 commented on Nov 5, 2026

   

   jappelbaum20

   on Nov 5, 2026

   More actions

   Same failure on Windows 11, T3 desktop with its local server, managed provider (openai_token_sharing), runtime 0.166.0, model gpt-6.1-terra. It matches the 2026-11-04 comment above: the model metadata request gets 401, and the next new session falls back to Unknown model gpt-6.1-terra.

   • Bad sessions: window 258,400, about 235k input tokens on the first request, and up to 50 compactions in one delegated child. Several children were looping at the same time.
   • It looks intermittent because a Codex desktop app on the same machine rewrites the shared models_cache.json (5-minute TTL). A test right after a desktop refresh passed, then later sessions failed again.

   Workaround that worked here, no catalog file needed: switch the provider instance to the existing ChatGPT CLI login instead of managed token sharing, keeping the same 0.166.0 binary. In settings.json:

   "config": { "setupMode": "existing", "binaryPath": "<home>\\.t3\\tools\\codex\\0.166.0\\bin\\codex.exe" }

   With the same binary under the ChatGPT login, after a T3 restart, a fresh delegated gpt-6.1-terra child got window 828,400, a first request of 38,454 tokens and the additional_tools record. The logs show auth_mode="Chatgpt" and no Unknown model or metadata warnings since. The serviceTier option also came back in the model options. Restart T3 after saving, because a running app-server keeps its old settings (#19025).

   Caveats:

   • setupMode isn't shown in the settings form.
   • binaryPath points into the managed tools folder, so a runtime update that removes 0.166.0 breaks it. A globally installed CLI is the safer path.

   +1 to the fix options in the comment above, especially keeping the /models token fresh and showing the Model metadata ... not found warning in the UI.
10. SinbadstheSailor commented on Nov 5, 2026

    

    SinbadstheSailor

    on Nov 5, 2026

    More actions

    Note

    🤖 Claude Opus 5.5 responding on behalf of Al

    Seeing the same chain on T3 Code 0.1.8-nightly.20261104.4192 with Codex 0.166.0, macOS arm64, desktop app, managed setup.

    New evidence: threads already running degrade too. One thread started at window 475,000 with 24,243 input tokens. On a later turn it dropped to 258,400 with 492,660 input tokens and went on to 433 compactions. The model lookup runs per turn (core/src/session/turn_context.rs:789, rust-v0.166.0). A new process restores it.

    Timing from one process: /models OK at 15:26:16, 15:30:47 and 15:35:18, then 401 at 15:39:48 and every 4:30 after. /responses kept working and recovered through its 401 path. First request on a healthy process was about 24,000 tokens, and about 263,000 on a failing one.

    Found by following the t3 triage playbook.
11. juliusmarminge commented on Nov 9, 2026

    

    juliusmarminge

    on Nov 9, 2026 – with GitCafe Production

    Member

    More actions

    Thanks for the detailed investigation. PR #30004, merged as 260297b55f, updates the managed runtime and upgrades existing managed installs, fixing the outdated-runtime catalog mismatch reported here. The later catalog-refresh 401 is a separate cause; please track that separately.
12. juliusmarminge

    closed this as completedon Nov 9, 2026