[Bug]: Connect with ChatGPT still rejects Codex sub-agents (forked sub-agent) and the thread can't continue (0.1.6)

Before submitting

I searched existing issues and did not find a duplicate. This is the same bug as Connect with ChatGPT rejects Codex subagents and leaves the chat unable to continue #17679 (closed), and it still reproduces on 0.1.6.
I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Connect Codex through Connect with ChatGPT (subscription sharing, modelProvider: openai_token_sharing).
In a thread, run a skill that spawns Codex sub-agents. Mine was code-review from the mattpocock-skills plugin, v1.3.1, commit 49dd158d1076134a641b33efb035946536778336 (skills/engineering/code-review/SKILL.md). It forks two sub-agents, /root/standards_review and /root/spec_review.
Wait for the forked sub-agent's first turn.
Send a follow-up message in the same thread.

Expected behavior

Either sub-agents work under subscription sharing, or T3 Code blocks or downgrades them before spawning (for example, it runs the reviews inline or says sub-agents are unavailable with this account). Either way, the parent thread should still accept the next message.

Actual behavior

The forked sub-agent thread (forkedFromId = the parent session) goes to systemError about 1.4 s after it starts. Its first request is rejected with subscription_sharing_unsupported_capability, param: "input". The forked history apparently contains an input item type that sharing doesn't accept. The parent turn then fails with "Codex used a feature that ChatGPT sharing does not support. Use another provider for this request."

The thread doesn't recover. My follow-up message about 10 minutes later failed the same way. I had to finish the work with another provider.

The error message doesn't name the feature (sub-agent spawning), so I had to dig through the provider log to find out what failed.

Impact

Blocks work completely

Version or commit

T3 Code server 0.1.6, codex-cli 0.166.0

Environment

Linux (NixOS), local server, Codex via Connect with ChatGPT (subscription sharing), model gpt-6.1-sol, effort medium

Logs or stack traces

From ~/.t3/userdata/logs/provider/events.<thread>.log, trimmed:

06:40:41.736Z item/started  {"type":"subAgentActivity","model":"gpt-6.1-sol","agentThreadId":"01a1a023-78c4-…","agentPath":"/root/standards_review"}  turnId 01a1a023-2678-…
06:40:41.757Z thread/read result  {"forkedFromId":"01a1a012-e59b-…","parentThreadId":"01a1a012-e59b-…","modelProvider":"openai_token_sharing","model":"gpt-6.1-sol"}
06:40:41.759Z turn/started (child) rootTurnId 01a1a023-2678-…
06:40:43.126Z thread/status/changed (child) {"type":"systemError"}
06:40:43.127Z error (child):
  {"error":{"message":"User subscription sharing currently supports only text, image, and file messages, item references, additional tools, compaction summaries, reasoning items, Web Search call items, developer function and custom tool call items, and programmatic tool calling items. Remove unsupported input items or use an API key instead.","type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}  willRetry:false
06:40:43.133Z turn/completed (child) status "failed"
06:40:50.858Z parent turn 01a1a023-2678-… -> provider_error "Codex used a feature that ChatGPT sharing does not support. Use another provider for this request."
06:51:21.555Z turn/start (user follow-up in same thread)
06:51:22.821Z -> same subscription_sharing_unsupported_capability error; turn fails again

Screenshots, recordings, or supporting files

Screenshot to follow in a comment.

code-review: Avoid native sub-agents under Codex ChatGPT sharing

I had that issue too and workaround is to disconnect codex and connect it using CLI instead of using "login with ChatGPT"

Thanks

@michalkow

@michalkow

I had that issue too and workaround is to disconnect codex and connect it using CLI instead of using "login with ChatGPT"

It works! Now I can actually use my free month of chatgpt pro

Another data point, with numbers, in case it helps triage. Windows 11, managed "Connect with ChatGPT" Codex instance (shadow home), model gpt-6.1-terra.

It is intermittent, not "sub-agents never work". I counted spawn_agent calls in the local Codex rollout files for one day: 25 calls, 24 returned a task_name normally (with and without model/fork_turns/reasoning_effort set). Exactly one got no output and ended the turn with:

Codex used a feature that ChatGPT sharing does not support. Use another provider for this request.

The only difference I can see: that call used task_name: "review", and another spawn_agent with the same task_name: "review" had been issued about one second earlier. Every other call used a unique name. This is a lead, not a proven cause.

The harmful part is what happens next. After that one failure, every later turn in the same thread failed with the same error, including plain user messages like "what is going on" and a /goal resume. So the thread cannot continue, which matches the title here. It looks as if the rejected item stays in the thread history and is sent again on each turn. A sub-agent that fails once should not make the whole thread unusable.

I have not yet tested the CLI-login workaround mentioned above on this setup.

Another data point, which may explain why this can appear suddenly after working for days.

Environment: T3 Code 0.1.7 desktop app, local server, macOS arm64, managed Codex 0.166.0, Connect with ChatGPT (openai_token_sharing), gpt-6.1-sol, effort xhigh.

What I see locally (Nov 2 to Nov 5):

Codex sub-agent origin	Completed	Interrupted	Failed
`app_owned` (`delegate_task`)	80	1	0
`provider_native` (`spawn_agent`)	0	0	4

All 18 earlier parent turns that delegated used delegate_task, despite the orchestration instruction preferring spawn_agent for same-provider children. Both PR-review turns on Nov 5 used spawn_agent, with a similar prompt, the same skills and the same effort.

What changed: the session's base instructions, on the same Codex version:

Sessions	Codex	Base instructions	Sub-agent path
Last PR reviews on Nov 4	0.166.0	20,751 chars, "You are a coding agent running in the Codex CLI"	`delegate_task`
Failing PR reviews on Nov 5	0.166.0	21,524 chars, "You are Codex, an agent based on GPT-6"	`spawn_agent`

After the runtime moved to 0.166.0 on Nov 4, sharing sessions alternated between these two versions. All sessions since 23:53 UTC on Nov 4 use the longer one.

My current ~/.codex/models_cache.json lists gpt-6.1-sol with multi_agent_version: "v2", while the running app-server has features.multi_agent=false and features.multi_agent_v2=false.

Hypothesis: with fallback metadata (as in #27939), the feature flags keep native agents off, so children go through delegate_task. Once the catalog entry for the model is applied, multi_agent_version: "v2" exposes spawn_agent despite those flags, which is the gap #28143 describes. This fits my data, but it is a correlation: the logs do not record the tool list, and I don't know why the alternation stopped when it did.

Failure pattern, both runs:

The first spawn_agent did not stop the parent, which kept working for about 11 to 12 s. The child failed within 2 s with subscription_sharing_unsupported_capability, param: "input", willRetry: false.
The parent turn failed within 2 s of the second spawn_agent.
In the first run, plain follow-up messages failed about 2 s after the turn started, even after a successful thread/resume. Handing off to Claude worked.
A new thread did not help: it made the same choice and failed the same way.

On the duplicate task_name lead above: the names in my two runs were unique within each turn, so that doesn't explain these failures. A spawn_agent call returning normally may also not show that the child succeeded, since my parent turn carried on after the first spawn while that child had failed.

The orchestration instructions at v0.1.7 (packages/provider-core/src/server/orchestrationInstructions.ts) don't appear to be limited by connection type, and they were present on these sharing turns. Sharing sessions may need to steer children to delegate_task until the catalog gap is closed.

Confirmed on T3 Code 0.1.7, macOS 26.5.1 arm64, with Codex CLI 0.167.0 and Connect with ChatGPT (model_provider=openai_token_sharing). Observed on November 7, 2026 with gpt-6.1-sol and gpt-6-astra.

I inspected five failed T3 conversations. Each initial failure was preceded by a failed native Codex subagent. In two conversations, subsequent plain-text retries failed again within seconds, without new assistant work. One of those was a fresh handoff conversation: it worked until it attempted another native subagent, then failed and remained stuck through two more retries.

The local Codex logs retain the underlying error, which T3's generic message hides:

{
  "type": "invalid_request_error",
  "param": "input",
  "code": "subscription_sharing_unsupported_capability"
}

The accompanying message says subscription sharing accepts only the listed supported input items and asks to remove unsupported items or use an API key. This is separate from a subscription usage-limit failure.

Read-only inspection of the running managed app-server processes confirms:

model_provider=openai_token_sharing
features.multi_agent=false
features.multi_agent_v2=false

There is no agents.enabled=false override. The local catalog entries for both affected models have multi_agent_version: "v2". The installed 0.1.7 bundle likewise includes the two feature flags but not the agents.enabled override proposed in #28143. This is consistent with the catalog fallback gap described there; I have not applied or tested that fix.

The exact outgoing Responses input item was not captured, so I cannot identify it independently or prove which retained item causes subsequent retries to fail. The observed child failure -> parent rejection -> immediate follow-up rejection sequence matches this issue.

Please include recovery for existing affected conversations as well as prevention of new native-agent starts. Naming the unsupported operation and surfacing error.param would also make the current error much easier to diagnose. Until the runtime restriction is fixed, directing sharing sessions to T3-owned delegate_task rather than native spawn_agent appears to be a useful mitigation.

Prepared with Codex assistance from read-only local run records, Codex logs, running launch arguments, model metadata, and the installed app bundle. Private task names, prompts, local paths, conversation identifiers, credentials, and raw log files are omitted.

Confirming another occurrence on T3 Code server 0.1.7, macOS / Apple Silicon (darwin arm64), using Codex, gpt-6-astra, high reasoning effort on November 9, 2026. This has happened to me a few times in the last week.

Observed sequence (UTC, from the T3 thread activity):

10:44:35: parent announces a native subagent for a bounded implementation task.
10:45:01: native subagent reports failed.
10:45:10: parent fails with Codex used a feature that ChatGPT sharing does not support. Use another provider for this request.
Two subsequent Continue messages at 11:03:35 and 11:04:03 both fail with the same error in approximately 5–6 seconds.
A recovery attempt at 11:05:45 explicitly asks to work directly without spawning subagents. It still fails at 11:05:50 with the identical error, before any new work is shown.

There is no active run or pending user question after failure. The restart action cannot restart an already-failed turn (thread_not_sendable: no running turn that can be restarted); starting a new turn succeeds operationally but immediately hits the same provider error.

Impact: an ongoing thread becomes unusable, and ordinary continuation cannot recover it. I did not want to switch provider/model. A fresh top-level thread with a concise handoff, keeping the same provider/model and existing checkout, has now started and emitted a progress update. Full task completion in the fresh thread is not yet verified.

Please handle unsupported subagent operations before they make the parent session unresumable, and provide a recovery path that preserves the conversation/work without requiring a provider switch. The timeline is consistent with the subagent-related failure reported here; the exact underlying cause has not been independently confirmed from raw provider logs.

No project source, private conversation contents, machine identifiers, or credentials are included in this report.

Also reproduces on 0.1.7 (macOS, T3 Code desktop "Beta" app, local server).

Setup: Codex via Connect with ChatGPT (modelProvider: openai_token_sharing), model gpt-6-astra, effort ultra.

What happened (from provider/events.<thread>.log, 2026-11-09):

12:37:21Z: turn/start with a plain text prompt (about payouts for a project). No skill or plugin involved.
12:37:48Z: Codex spawned a forked sub-agent, item/started subAgentActivity with agentPath: /root/payout_email_evidence, model gpt-6-astra, reasoning effort xhigh. The new thread has forkedFromId set to the parent session.
12:37:56Z: the fork goes to thread/status/changed systemError, about 7 s after it started. The error is:
{"error":{"message":"User subscription sharing currently supports only text, image, and file messages, item references, additional tools, compaction summaries, reasoning items, Web Search call items, developer function and custom tool call items, and programmatic tool calling items. Remove unsupported input items or use an API key instead.","type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}
The parent turn then ends failed. The UI shows only "Codex used a feature that ChatGPT sharing does not support. Use another provider for this request.", shown on the sub-agent's "Payout Email Evidence" step with a "Failed 8s" badge.

Same failure as the original report: the forked sub-agent's first request is rejected on input, and the UI message never says the feature is sub-agent spawning. The cause is only visible in the provider log.

This reproduces with an ordinary prompt, so it is not specific to a skill. Any prompt where Codex decides to spawn a sub-agent can trigger it.

Workarounds: switch the thread to another provider, or use an OpenAI API key instead of Connect with ChatGPT.

Evidence gathered and this comment drafted by Claude Sonnet 5.5 (Claude Code) via the T3 Code triage playbook; reviewed and approved by the user before posting.

Same failure here on 0.1.7. macOS arm64, Connect with ChatGPT, managed Codex 0.166.0, gpt-6.1-sol.

What happened:

Plain text prompt. Codex started one native sub-agent on its own.
The sub-agent failed in about 2 seconds with subscription_sharing_unsupported_capability, param: input.
The parent failed next.
"try again" failed in about 1 second.
A fresh thread with one spawn_agent call failed the same way.

Why this matters: a new user does not choose sub-agents here. The model does. Then the whole thread is dead, and the error does not say why.

Main still has only features.multi_agent=false and features.multi_agent_v2=false in CodexManagedRuntime.ts. Those flags have not stopped this.

The open fixes:

fix(codex): prevent catalog agents in ChatGPT sharing #28143 adds agents.enabled=false. It is labeled pr:needs-julius and has no human review yet.
fix(server): recover Codex sessions after sharing rejection #28962 lets a rejected thread recover.

Can a maintainer make a call on #28143? If it is the wrong approach, a short note on the preferred fix would help. Even without #28143, #28962 would stop one failure from killing the thread.

Same failure here on 0.1.7. macOS arm64, Connect with ChatGPT, managed Codex 0.166.0, gpt-6.1-sol.

What happened:

Plain text prompt. Codex started one native sub-agent on its own.
The sub-agent failed in about 2 seconds with subscription_sharing_unsupported_capability, param: input.
The parent failed next.
"try again" failed in about 1 second.
A fresh thread with one spawn_agent call failed the same way.

Workaround confirmed: switching Codex to "Use existing CLI" and restarting T3 Code fixed it. The same one-helper test returned its reply.

Why this matters: a new user does not choose sub-agents here. The model does. Then the whole thread is dead, and the error does not say why.

Main still has only features.multi_agent=false and features.multi_agent_v2=false in CodexManagedRuntime.ts. Those flags have not stopped this.

The open fixes:

fix(codex): prevent catalog agents in ChatGPT sharing #28143 adds agents.enabled=false. It is labeled pr:needs-julius and has no human review yet.
fix(server): recover Codex sessions after sharing rejection #28962 lets a rejected thread recover.

Can a maintainer make a call on #28143? If it is the wrong approach, a short note on the preferred fix would help. Even without #28143, #28962 would stop one failure from killing the thread.

Confirmed on T3 Code Beta 0.1.8, macOS 27.2.1 (arm64), Codex CLI 0.163.0 (version recorded in the affected rollout), with Connect with ChatGPT (model_provider: openai_token_sharing), gpt-6-astra, effort max. Observed on November 10, 2026.

The local Codex rollout contains a concrete input-item lead: response_item.payload.type: "agent_message" immediately before both the child's first rejection and the parent's rejection.

Observed sequence (UTC; summaries extracted from the rollouts, with private prompts and identifiers omitted):

08:45:42.804 parent: function_call namespace=collaboration name=spawn_agent
08:45:43.121 parent: function_call_output returns the child task name successfully
08:45:45.909 child:  response_item type=agent_message
                     content types=[input_text, encrypted_content]
                     input_text begins "Message Type: NEW_TASK"
08:45:48.145 child:  task_complete with subscription_sharing_unsupported_capability
08:46:05.345 parent: emits another tool call (so spawn_agent itself did not immediately stop it)
08:46:08.575 parent: response_item type=agent_message
                     content types=[input_text]
                     text begins "Message Type: FINAL_ANSWER" and reports "Agent errored"
08:46:10.839 parent: task_complete with subscription_sharing_unsupported_capability
08:48:55.476 parent: plain user follow-up asking to resume
08:48:57.668 parent: same rejection, with no new assistant work
08:49:07.040 parent: another plain user follow-up
08:49:08.327 parent: same rejection again

The underlying error in all three parent failures is:

{
  "type": "invalid_request_error",
  "param": "input",
  "code": "subscription_sharing_unsupported_capability"
}

The accompanying message lists the accepted input items and says: "Remove unsupported input items or use an API key instead."

Interpretation: the child's agent_message is the leading unsupported-item candidate, and its failure notification introduces another agent_message into the parent history. That item remains in the recorded history across both retries. This strongly supports the retained-history explanation for why ordinary follow-ups cannot recover the conversation. The exact outgoing HTTP request was not captured, and the server error does not identify an input index, so this is a rollout-based diagnosis rather than a separately isolated minimal API reproduction. The parent notification contains plain input_text only, which also suggests this is not solely about the child's encrypted task content.

The affected session also includes T3's orchestration instruction to prefer native subagents for same-provider/same-settings children. The thread has no active run or pending user question after failure. Project files remain on disk, but the conversation cannot continue.

Please cover recovery of existing affected sessions as well as prevention of incompatible native-agent starts. I have not tested the CLI-login workaround in this setup.

Prepared with Codex assistance from local read-only diagnostics. No raw logs, private prompts, local paths, conversation identifiers, or credentials are included.

Additional reproduction on Windows, November 11, 2026: T3 Code desktop 0.1.8, managed Codex CLI 0.166.0, Connect with ChatGPT (openai_token_sharing), gpt-6.1-sol.

A design-critique skill requested two independent native sub-agents. After user approval, both children failed. The parent then failed with:

Codex used a feature that ChatGPT sharing does not support. Use another provider for this request.

Sending continue failed again without further assistant work. A subsequent request to prepare a T3 Code PR failed the same way. A separate conversation was needed to investigate.

Read-only local diagnostics found:

The running managed app-server already has both features.multi_agent=false and features.multi_agent_v2=false.
Both child rollouts identify Codex 0.166.0 and openai_token_sharing.
Each child records an agent_message containing input_text and encrypted_content, followed about one second later by subscription_sharing_unsupported_capability.
The T3 thread history confirms both children failed and that two subsequent user turns failed with the same error.

This matches #29992. The proposed prevention fix is #28143 (agents.enabled=false); the proposed recovery fix for affected conversation history is #28962. Both PRs remain open as of this investigation.

The exact outgoing HTTP request was not captured, and neither proposed fix was applied or tested locally. These are observations from the original failing session, not a new controlled reproduction. No raw prompts, encrypted payloads, credentials, local paths, or conversation identifiers are included.

Prepared with gpt-6.1-sol through the Codex harness in T3 Code.

Additional evidence from Linux x64, T3 0.1.7 (322f6544dfad), Codex 0.167.1, managed Connect with ChatGPT (openai_token_sharing), gpt-6.1-sol, November 11, 2026. This confirms the same problem on the current stable Codex CLI, with an independent local check of the prevention proposed in #28143.

Is an upgrade sufficient?

The managed launch configuration is identical in T3 v0.1.7, v0.1.9 (latest stable checked today), and current main (7e565c510d6d): Git blob 3704c919c2791e30e1014ef23d8b11c6820a9c71. All contain both false feature flags; none adds agents.enabled=false. The affected running process already had both false flags. Upgrading T3 alone is therefore not a demonstrated remedy. Codex 0.167.1 is also the latest stable Codex release checked today.

Source-level explanation and isolated before/after check

In Codex 0.167.1's configuration resolver, false features.multi_agent / features.multi_agent_v2 do not establish an explicit disabled override when agents.enabled retains its default true. multi_agent_version_for_model can consequently use the model's multi_agent_version: "v2". Setting agents.enabled=false provides the disabled override ahead of model metadata, provided features.multi_agent_v2 remains false.

I checked this with the actual Codex 0.167.1 binary, an empty temporary CODEX_HOME per case, --ignore-user-config, a local model catalog advertising v2, and a loopback-only mock Responses endpoint. The mock inspected the outbound tool definitions in input[].additional_tools, then intentionally returned HTTP 400 to stop the invocation without generating model output. Exactly one local request was observed in each case; no credentials or real provider requests were used.

[
  {
    "override": "feature flags only",
    "native_collaboration_tools": [
      "collaboration.followup_task",
      "collaboration.interrupt_agent",
      "collaboration.list_agents",
      "collaboration.send_message",
      "collaboration.spawn_agent",
      "collaboration.wait_agent"
    ]
  },
  {
    "override": "feature flags plus agents.enabled=false",
    "native_collaboration_tools": []
  }
]

This verifies tool suppression by the proposed override on 0.167.1. It does not claim a successful real-account T3 conversation, recovery of existing history, or compatibility testing of older CLI releases. The temporary probe did not modify the live install, user configuration, model cache, or any original session.

Minimal original incident trace

The following is an allowlisted field projection of the original parent and two child JSONL rollouts, sorted by timestamp. source_line refers to the original rollout line; session names are aliases. No prompts, task payloads, encrypted content, conversation identifiers, credentials, or local paths are included. Times are UTC. This is the original incident evidence, separate from the local mock check above.

{"timestamp":"2026-11-11T17:15:51.654Z","session":"root","source_line":1,"event":"session_meta","cli_version":"0.167.1","model_provider":"openai_token_sharing"}
{"timestamp":"2026-11-11T17:15:51.677Z","session":"root","source_line":10,"event":"turn_context","model":"gpt-6.1-sol","multi_agent_version":"v2"}
{"timestamp":"2026-11-11T17:16:30.054Z","session":"root","source_line":53,"event":"function_call","name":"spawn_agent"}
{"timestamp":"2026-11-11T17:16:30.087Z","session":"worker-1","source_line":1,"event":"session_meta","cli_version":"0.167.1","model_provider":"openai_token_sharing"}
{"timestamp":"2026-11-11T17:16:30.103Z","session":"worker-1","source_line":13,"event":"agent_message","content_types":["input_text","encrypted_content"]}
{"timestamp":"2026-11-11T17:16:30.934Z","session":"worker-1","source_line":14,"event":"task_complete","error":{"type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}
{"timestamp":"2026-11-11T17:16:36.192Z","session":"root","source_line":59,"event":"function_call","name":"spawn_agent"}
{"timestamp":"2026-11-11T17:16:36.215Z","session":"worker-2","source_line":1,"event":"session_meta","cli_version":"0.167.1","model_provider":"openai_token_sharing"}
{"timestamp":"2026-11-11T17:16:36.229Z","session":"worker-2","source_line":13,"event":"agent_message","content_types":["input_text","encrypted_content"]}
{"timestamp":"2026-11-11T17:16:36.258Z","session":"root","source_line":65,"event":"agent_message","content_types":["input_text"]}
{"timestamp":"2026-11-11T17:16:36.998Z","session":"worker-2","source_line":14,"event":"task_complete","error":{"type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}
{"timestamp":"2026-11-11T17:16:37.036Z","session":"root","source_line":67,"event":"task_complete","error":{"type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}
{"timestamp":"2026-11-11T17:33:35.635Z","session":"root","source_line":70,"event":"turn_context","model":"gpt-6.1-sol","multi_agent_version":"v2"}
{"timestamp":"2026-11-11T17:33:35.637Z","session":"root","source_line":71,"event":"ordinary_user_followup","content_omitted":true}
{"timestamp":"2026-11-11T17:33:36.626Z","session":"root","source_line":74,"event":"agent_message","content_types":["input_text"]}
{"timestamp":"2026-11-11T17:33:36.627Z","session":"root","source_line":75,"event":"task_complete","error":{"type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}
{"timestamp":"2026-11-11T18:01:15.260Z","session":"root","source_line":78,"event":"turn_context","model":"gpt-6.1-sol","multi_agent_version":"v2"}
{"timestamp":"2026-11-11T18:01:15.263Z","session":"root","source_line":79,"event":"ordinary_user_followup","content_omitted":true}
{"timestamp":"2026-11-11T18:01:18.483Z","session":"root","source_line":81,"event":"task_complete","error":{"type":"invalid_request_error","param":"input","code":"subscription_sharing_unsupported_capability"}}

Both children fail immediately after their native agent_message task input. A child failure notification adds another agent_message to the parent, which then fails; both ordinary follow-ups fail again. The server error identifies unsupported input but no item index, so the retained-history explanation is supported by these records, not by a captured original outbound HTTP request.

The source areas are:

Managed launch overrides: prevention covered by existing fix(codex): prevent catalog agents in ChatGPT sharing #28143.
Orchestration instructions: still tell Codex to prefer native spawn_agent for same-provider work, without a sharing-transport exception.
Recovery of already-affected native history remains separate, covered by existing fix(server): recover Codex sessions after sharing rejection #28962.

Both PRs remain open and unmerged as checked today. This evidence supports the existing work; no duplicate issue or PR was opened.

Prepared with GPT-6.1 Sol through the Codex harness in T3 Code.

I tried to reproduce this on the current build and could not.

Commit 62dc589 (origin/main). An end-to-end run is not possible on a worker: it needs a real Connect with ChatGPT (openai_token_sharing) login, so I did not see the sharing rejection or the stuck thread myself. Root-cause check with the real Codex CLI 0.167.2: I ran codex exec with an empty CODEX_HOME, --ignore-user-config, model gpt-6.1-sol, and main's exact managed launch args from CodexManagedRuntime.ts (model_provider=openai_token_sharing, features.api_key_model_discovery=true, features.multi_agent=false, features.multi_agent_v2=false). The provider base_url pointed at a loopback mock that served Codex's bundled catalog (gpt-6.1-sol has multi_agent_version "v2") and answered 400 on /v1/responses. The first outgoing request offered the collaboration tools spawn_agent, wait_agent, send_message, list_agents, followup_task and interrupt_agent. The same run with -c agents.enabled=false added sent none of them. So on main the model is still offered native sub-agents under ChatGPT sharing, and the reports show sharing rejecting those sub-agents with subscription_sharing_unsupported_capability. Failing test: one assertion that the managed launch args include agents.enabled=false, added to the existing case in apps/server/src/provider/CodexManagedRuntime.test.ts. All 4 parameterised cases fail on that assertion only, and the file passes 4/4 without it.

Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.

Following the request for exact steps and versions: the failure reproduced in three fresh histories using a real ChatGPT-sharing connection.

Environment and method

Original affected installation: T3 Code 0.1.9, Linux x64, desktop .deb.
Controlled trials: isolated codex app-server processes, Codex 0.166.0, gpt-6.1-sol, medium effort, openai_token_sharing.
A local catalog file supplied the cached model entry with multi_agent_version: "v2".
Retained features.api_key_model_discovery=true, features.multi_agent=false, and features.multi_agent_v2=false.

A loopback inspection proxy forwarded requests to the real OpenAI Responses API. These were isolated provider-level trials, not a patched desktop-UI end-to-end test.

Reproduction

For each fresh history:

Send: Use no tools. Reply exactly BASELINE_OK.
Request one native collaboration.spawn_agent, with fork_turns="none", model gpt-6.1-sol, medium effort, and the task Use no tools. Reply exactly WORKER_OK. Ask the parent to wait using collaboration.wait_agent; prohibit shell, browser, MCP, and filesystem tools.
Send in the parent history: Use no tools. Reply exactly FOLLOWUP_OK.

In all three trials, the baseline completed, then both the native-spawn turn and ordinary parent follow-up failed with:

HTTP 400
type: invalid_request_error
code: subscription_sharing_unsupported_capability
param: input

Rollout records confirmed one actual native spawn per history—not T3’s delegate_task—with fork_turns="none".

New outgoing-request evidence

The rejected requests contained agent_message input items. In one controlled replay, removing only the single agent_message item from the rejected follow-up changed the response to HTTP 200. That records HTTP acceptance, not a completed streamed assistant response.

The proxy saved only allowlisted item/tool names and response status/error metadata, not complete request bodies or authorization headers.

Existing fixes

fix(codex): prevent catalog agents in ChatGPT sharing #28143: with agents.enabled=false, a real-provider trial advertised no collaboration tools, answered AGENTS_UNAVAILABLE to the worker request, and completed the ordinary follow-up.
fix(server): recover Codex sessions after sharing rejection #28962: all nine recovery scenarios passed in T3’s orchestration/SQLite integration harness using a deterministic adapter. Separately, three fresh real-provider sessions seeded with a small plaintext summary answered and completed another follow-up. That does not exercise the PR’s automatic recovery path against the real provider.

Both production diffs were applied unchanged to main 5ccc65be0a2b; the recovery test file required a temporary conflict resolution. Together, the two relevant files passed 71 tests, and server-only typechecking passed with Node 26.12.1.

This is version- and configuration-specific evidence supporting the existing PRs, not a claim that every native-agent configuration fails. The installed app and existing threads were not modified.

Investigation assisted by GPT-6.1 Sol through Codex in T3 Code.

Reproduced on Windows on 14 November 2026, following the request for exact steps and versions.

Environment: Windows 11, T3 Code (Beta) desktop 0.1.6 with local server, managed "Connect with ChatGPT" (openai_token_sharing), Codex 0.167.0 (version recorded in the affected rollouts), gpt-6-astra, low effort. The running app-server had both features.multi_agent=false and features.multi_agent_v2=false.

Steps, on a brand-new thread:

Ask Codex to start one native sub-agent whose only task is to reply with one word, and wait for it.
The turn fails with "Codex used a feature that ChatGPT sharing does not support."
Send "reply OK" in the same thread. It fails the same way.
Switch that thread to a Claude provider and send the same message. It answers.

Same PC, same account, after switching the Codex entry to setupMode: "existing" (Codex 0.167.0): step 1 returns the sub-agent's word and step 3 answers. Seen in our logs on 7, 11, 12 and 14 November.

We applied both open fixes to a fork based on 09a54f01bc:

28143 applied cleanly.
28962: the production file applied cleanly. The test file needed one small conflict resolution (the fork's test adapter has no cancelledRunOrdinals).
ProviderSwitch.integration.test.ts: 58 of 58 pass, including all 9 "recovers rejected Codex history" cases. Server typecheck is clean.

This is fork-level evidence on Windows, not a patched desktop run against the real provider.

Investigated and written with Claude (Fable 5.2) in T3 Code, posted at the user's request.

Navigation Menu

Repository navigation

[Bug]: Connect with ChatGPT still rejects Codex sub-agents (forked sub-agent) and the thread can't continue (0.1.6) #29992

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Is an upgrade sufficient?

Source-level explanation and isolated before/after check

Minimal original incident trace

Environment and method

Reproduction

New outgoing-request evidence

Existing fixes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Connect with ChatGPT still rejects Codex sub-agents (forked sub-agent) and the thread can't continue (0.1.6) #29992

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Activity

sigboe commented on Nov 3, 2026

michalkow commented on Nov 3, 2026

sigboe commented on Nov 3, 2026

sigboe commented on Nov 3, 2026

lamat1111 commented on Nov 5, 2026

petar-simeta commented on Nov 5, 2026

crestonepeaks commented on Nov 7, 2026

GitariDev commented on Nov 9, 2026

MalikElate commented on Nov 9, 2026

RileySpiller commented on Nov 9, 2026

RileySpiller commented on Nov 9, 2026

VirtuozTM commented on Nov 10, 2026

TomLeppens99 commented on Nov 11, 2026

Syed-Ahmed02 commented on Nov 11, 2026

Is an upgrade sufficient?

Source-level explanation and isolated before/after check

Minimal original incident trace

juliusmarminge commented on Nov 12, 2026

dotspace42 commented on Nov 13, 2026

Environment and method

Reproduction

New outgoing-request evidence

Existing fixes

iamsoft-tech commented on Nov 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions