SuperrNaruto (#1237), and PennyVibe on #1109 with v0.1.1108: Codex
with the lead and its subagents all on one custom Responses provider
serving gpt-6-astra. #1109's fix sends the subagent's sealed task back
to that provider, and the subagents ran. But when a subagent answers
the lead with send_message, Codex hands the lead an agent_message to
/root whose payload the provider sealed, and hasSealedAgentMessage
marks the lead's next turn as a sealed task. The lead has no parent
thread, so leadProvider found nobody, sealedReader accepted only a
ChatGPT account, and the lead was refused before anyone was asked with
"This subagent's task was sealed by the ChatGPT backend that answered
its lead ... is neither". The main conversation stopped while the
subagents finished.
The providers that can read a sealed message are now those that
answered the lead (the parent thread, as before) and the one that
answered the request's own conversation (leadProvider of its
conversationID): a subagent sent a task sealed by the lead's provider
had to be on that provider, so its reply was sealed there too. A lead
moved to another provider, one magpie never answered, and a subagent
whose lead a ChatGPT account answered are still refused before anyone
is asked, with the same messages.
Verified: TestSealedReplyGoesBackToTheProviderThatAnsweredTheLead
(lead, subagent, then the lead with the subagent's sealed FINAL_ANSWER
reply, all on third/gpt-6-astra with Codex's web_search tool) fails on
origin/main with the reporter's exact 400 and passes with the change;
the reply's ciphertext reaches the provider as it came.
TestSealedReplyRefusedWhereTheLeadWasNotAnswered and
TestSealedTaskFromChatGPTLeadStillRefused (lead on gpt-5.5 through the
ChatGPT sign-in, subagent on the custom provider) pass on both. go test
-tags nogui ./internal/gateway passes; the sealed tests pass under
-race -count=5; go vet -tags nogui ./internal/gateway passes for
darwin, linux and windows. Not tried with real Codex and a real relay
of the ChatGPT backend: the reply's item is built from the
"Message Type: FINAL_ANSWER / Task name / Sender / Payload" layout in
the codex 0.160.1 binary and PennyVibe's description, not from a
captured request.
yetone
1efa4c642f