Sign up
View stargazersSign up

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

opened4d agobyLLuka-Bazooka

Summary

T3 offers gpt-6.1-sol while its managed installer pins Codex 0.156.1, which receives no metadata for that model. Codex falls back to direct tool exposure, consuming 218,396 input tokens for a fresh chat containing only hi.

Updating only the managed runtime to Codex 0.166.0 resolved the observed bloat with all tools enabled:

Fresh in-app hi requestCodex 0.156.1Codex 0.166.0
Input tokens218,39626,752
Reported usable context window258,400475,000
Missing-metadata warningPresentAbsent

Both tests used T3 nightly 0.1.6-nightly.20261031.3956, the same managed provider, and the same tool configuration. The upgraded reply completed and was visible in T3.

Confirmed catalog mismatch

Diagnostic replays of T3's configured https://api.openai.com/v1/models request used the same managed credentials and changed only client_version. All returned HTTP 200:

client_versionModels returned6.1 Sol metadata
0.156.1 (T3's pin), 0.158.08Missing
0.159.0, 0.160.0, 0.163.010Present
Omitted10Present

T3's model manifest permits 6.1 Sol from 0.153.0, below the tested catalog-availability boundary between 0.158.0 and 0.159.0. The server's reason for that cutoff is not exposed by the response.

The pinned runtime's bundled catalog also lacks the model. Its fallback metadata has no tool_mode; source inspection confirms direct exposure with the observed configuration. The returned 6.1 metadata specifies tool_mode: "code_mode_only" and a 500,000-token window.

The affected turn logs:

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

Reproduction

  1. Use Windows desktop nightly .3956, the managed ChatGPT-sharing Codex provider, and its pinned runtime 0.156.1, with existing app integrations enabled.
  2. Create a fresh scratch chat, select gpt-6.1-sol, and send hi.
  3. Inspect the first thread/tokenUsage/updated snapshot and metadata warning.
  4. Switch only the managed runtime to official Codex 0.166.0 and repeat in another fresh chat.

Expected: a selectable supported model uses the correct metadata and leaves working context available while retaining connected tools.

Observed on the affected installation; a clean-install reproduction has not been performed.

Environment and verification

  • Windows x86_64, OS build 10.0.26300; T3 desktop against its local Windows server.
  • Provider: openai_token_sharing; shared Codex home, no shadow home.
  • T3: 0.1.6-nightly.20261031.3956; initially also observed on .3917.
  • The upgrade used the official SHA-256-verified managed package. Provider initialization confirmed T3 Code/0.166.0.
  • No static catalog override, tool-disabling flag, configuration change, or T3 source patch was used for the successful upgrade test. The previous runtime was preserved for rollback.
  • A separate inventory probe using the identical 0.166.0 executable exposed all 383 connector tools, plus 3 computer-use and 4 Node tools. T3 supplied its normal MCP setup in the actual chat. Inventory and a basic reply were verified; every third-party connector operation was not exercised.

Remaining upstream concern

Managed installation supplies a runtime that cannot discover metadata for a model T3 offers. Please triage how managed runtime selection and selectable model support should align.

Related: #21249 (updates beyond the managed pin), #26707 / #27790 (missing native metadata and reasoning controls).

The model comparison and detailed catalog/upgrade evidence remain in the comments as investigation history.

Prepared and updated by Codex (GPT-6), using local source inspection, authenticated catalog replays, and in-app verification, at the reporter's request.

LLuka-Bazooka4d ago
Synced from GitHub

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:

ModelFirst-request input tokensReported context window
gpt-6-sol21,279258,400
gpt-6.1-sol218,396258,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:

text
1Model 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.

LLuka-Bazooka4d ago
Synced from GitHub

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/modelsModels returnedgpt-6.1-sol metadata
client_version=0.156.1 (T3's pinned runtime)8Missing
client_version=0.158.08Missing
client_version=0.159.010Present
client_version=0.160.010Present
client_version=0.163.010Present
Parameter omitted10Present

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:

text
1d559bb88e74d471265857b93b7f19bc250dae527673b9191b33534478093f6bc

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:

text
1T3 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 requestBefore, Codex 0.156.1After, Codex 0.166.0
Input tokens218,39626,752
Output tokens4714
Reported usable context window258,400475,000
Missing-model-metadata warningPresentAbsent

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.

  • #21249 remains open to allow T3-managed runtimes to update beyond their pinned release.
  • #26707 and #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.

Aai-scott4d ago
Synced from GitHub

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:

toml
1model_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.
Sshuaces3d ago
Synced from GitHub

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.

Eethanjnrg3d ago
Synced from GitHub

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.