MultiAgentV2 encrypted spawn_agent schema returns 400: model not configured for encrypted tool use

Resolved 💬 19 comments Opened Jun 6, 2026 by lovingfish Closed Jun 6, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What happened?

After updating to the current alpha CLI, enabling features.multi_agent_v2 makes every Codex turn fail before the model handles the prompt.

This happens even when the prompt does not ask to use a subagent, because the model-visible functions.spawn_agent tool schema is rejected by the API request validator.

Minimal repro

Config:

[features]
multi_agent_v2 = true

Command:

codex exec --json --ephemeral --skip-git-repo-check -C /tmp 'Reply exactly: DONE'

Actual behavior

The turn fails with a 400 response:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "Invalid Value: 'tools'. Function 'functions.spawn_agent' declares encrypted parameters but is not configured for encrypted tool use by this model.",
    "param": "tools"
  },
  "status": 400
}

I also reproduced the same failure with gpt-5.4 and gpt-5.4-mini, so this does not appear to be limited to one selected model slug.

Expected behavior

Either:

the selected model/backend accepts the MultiAgentV2 encrypted tool schema, or
Codex avoids exposing encrypted MultiAgentV2 tools unless the active model/backend is configured for encrypted tool use.

At minimum, a user config that enables multi_agent_v2 should not make unrelated turns fail at request validation time.

Workaround

Disabling MultiAgentV2 avoids the 400:

codex exec --json --ephemeral --skip-git-repo-check -C /tmp --disable multi_agent_v2 'Reply exactly: DONE'

With multi_agent_v2 disabled, the legacy/stable subagent flow still works for spawn/wait in my local repro.

Suspected regression

This looks related to #26210 (Encrypt multi-agent v2 message payloads), which marks MultiAgentV2 spawn_agent, send_message, and followup_task message parameters as encrypted.

Relevant local source path after pulling latest:

codex-rs/core/src/tools/handlers/multi_agents_spec.rs marks spawn_agent.message with with_encrypted()
codex-rs/tools/src/json_schema.rs serializes the encrypted schema marker
codex-rs/core/src/tools/spec_plan.rs includes direct model-visible tools in the request whenever multi_agent_v2 is enabled

Environment

Codex CLI: 0.138.0-alpha.6
OS: WSL Ubuntu 24.04 on Windows 11
Auth/provider: normal Codex CLI login
Repro confirmed after git pull --ff-only in a local openai/codex checkout

View original on GitHub ↗

19 Comments

WindLucker · 1 month ago

Can confirm this behavior. It seems this issue was introduced with the release of version 0.137.0. Rolling back to 0.136.0 resolves the error and works fine as a temporary fix.

etraut-openai contributor · 1 month ago

The multiagent v2 feature is still under development. We don't recommend its use, and we are not taking bug reports on this feature at this time.

lovingfish · 1 month ago

The multiagent v2 feature is still under development. We don't recommend its use, and we are not taking bug reports on this feature at this time.

ok, roll back to multiagent v1 and works normally

xsyetopz · 1 month ago

Same thing happens on multi_agent stable on release 0.138.0.

@etraut-openai could y'guys STOP breaking f**king production? Holy Heavens, ever heard of QA?

cowwoc · 1 month ago

@etraut-openai I filed https://github.com/openai/codex/issues/27205 for the issue that @xsyetopz mentioned. It makes 0.138.0 unusable (literally can't send any prompt) for me.

agirardeau · 1 month ago

Same issue for me on 0.139.0, rolled back to 0.137.0.

jiabaogithub · 1 month ago

marked,same issue

thoughtdna · 1 month ago

The multiagent v2 feature is still under development. We don't recommend its use, and we are not taking bug reports on this feature at this time.

this is one of the saddest responses I have read. Poor form.

septrcode · 1 month ago

Can confirm this behavior. It seems this issue was introduced with the release of version 0.137.0. Rolling back to 0.136.0 resolves the error and works fine as a temporary fix.

did this only work for the cli or for desktop too? i just rolled the cli back desktop still borked

xsyetopz · 1 month ago

> Can confirm this behavior. It seems this issue was introduced with the release of version 0.137.0. Rolling back to 0.136.0 resolves the error and works fine as a temporary fix. did this only work for the cli or for desktop too? i just rolled the cli back desktop still borked

revert to 0.136, or better yet, just stick to 0.128 or 0.130 as last proven functional-enough versions. It's starting to seem like openai/codex developers are catering to influencer-demo prose rather than actual function && stability of the tool.

It is unfortunate, but y'might want to reconsider...

septrcode · 1 month ago

> > Can confirm this behavior. It seems this issue was introduced with the release of version 0.137.0. Rolling back to 0.136.0 resolves the error and works fine as a temporary fix. > > > did this only work for the cli or for desktop too? i just rolled the cli back desktop still borked revert to 0.136, or better yet, just stick to 0.128 or 0.130 as last proven functional-enough versions. It's starting to seem like openai/codex developers are catering to influencer-demo prose rather than actual function && stability of the tool. It is unfortunate, but y'might want to reconsider...

yeah i realize now "experimental" doesnt mean cool extra shit it means my stuff can break at any time so not doing that again, but i ask cuz im stuck, im about to try and find an older version of desktop dmg but as far as cli goes:

"Separate from the app, your terminal npm CLI was originally:
codex-cli 0.130.0
@openai/codex@0.130.0
and now it is:
codex-cli 0.136.0
@openai/codex@0.136.0"

so i was on what you said and didnt realize but desktop still wont run that chat and i really need to finish that chat lol

xsyetopz · 1 month ago

> > > Can confirm this behavior. It seems this issue was introduced with the release of version 0.137.0. Rolling back to 0.136.0 resolves the error and works fine as a temporary fix. > > > > > > did this only work for the cli or for desktop too? i just rolled the cli back desktop still borked > > > revert to 0.136, or better yet, just stick to 0.128 or 0.130 as last proven functional-enough versions. It's starting to seem like openai/codex developers are catering to influencer-demo prose rather than actual function && stability of the tool. > It is unfortunate, but y'might want to reconsider... yeah i realize now "experimental" doesnt mean cool extra shit it means my stuff can break at any time so not doing that again, but i ask cuz im stuck, im about to try and find an older version of desktop dmg but as far as cli goes: "Separate from the app, your terminal npm CLI was originally: codex-cli 0.130.0 @openai/codex@0.130.0 and now it is: codex-cli 0.136.0 @openai/codex@0.136.0" so i was on what you said and didnt realize but desktop still wont run that chat and i really need to finish that chat lol

I have an .app for a really old version, like maybe a month old (pre-5.5). would that help?

septrcode · 1 month ago

> > > > Can confirm this behavior. It seems this issue was introduced with the release of version 0.137.0. Rolling back to 0.136.0 resolves the error and works fine as a temporary fix. > > > > > > > > > did this only work for the cli or for desktop too? i just rolled the cli back desktop still borked > > > > > > revert to 0.136, or better yet, just stick to 0.128 or 0.130 as last proven functional-enough versions. It's starting to seem like openai/codex developers are catering to influencer-demo prose rather than actual function && stability of the tool. > > It is unfortunate, but y'might want to reconsider... > > > yeah i realize now "experimental" doesnt mean cool extra shit it means my stuff can break at any time so not doing that again, but i ask cuz im stuck, im about to try and find an older version of desktop dmg but as far as cli goes: > "Separate from the app, your terminal npm CLI was originally: codex-cli 0.130.0 @openai/codex@0.130.0 and now it is: codex-cli 0.136.0 @openai/codex@0.136.0" > so i was on what you said and didnt realize but desktop still wont run that chat and i really need to finish that chat lol I have an .app for a really old version, like maybe a month old (pre-5.5). would that help?

legit i was about to say yes and risked it on this, EVERYBODY THIS WORKED AND MY APP IS CRYING TO UPDATE MY CHAT IS COOKIN AGAIN

https://codex.en.uptodown.com/mac/download/1176643411

smashah · 1 month ago

i dont recall setting this breaking config to true. why was this done on a minor version revision? does this software not use semver? very strange that this is set as not planned.

ignatremizov · 1 month ago

Not only that, #26210 also made v2 subagent task data in rollouts unreadable+encrypted. Please react or comment on #28058 if auditability matters for your workflow.

theTrident · 1 month ago

Same issue for me on 0.125.0

theTrident · 1 month ago

Same issue for me on 0.125.0

The same configuration worked on codex cli version 0.137.0.

Alek2077 · 16 days ago

This remains operationally concerning in 0.142.5. The current binary still labels multi_agent_v2 as under development, and the collaborator guidance here says V2 is not recommended. However, the current GPT-5.5 model catalog sets multi_agent_version: v2, and Codex gives that model-level value precedence over features.multi_agent_v2=false.

I reproduced the following:

features list reports multi_agent_v2 ... false.
A fresh GPT-5.5 thread nevertheless exposes the V2 task_name/fork_turns schema.
Changing that thread to GPT-5.4 leaves it on V2.
A fresh GPT-5.4 thread uses V1 and spawns a GPT-5.4-mini child successfully.
A V2 child test failed with Encrypted function output content could not be decrypted or decoded.

This means users cannot both use GPT-5.5 and follow the recommendation to avoid V2. Shipping the implementation behind an under-development flag is understandable; model metadata silently overriding an explicit local disable is a different issue. It makes the public recommendation and the effective GPT-5.5 behavior inconsistent.

It also makes the current custom-agent documentation inaccurate for GPT-5.5. The documented ~/.codex/agents/ profiles can pin model, reasoning effort, sandbox, and developer instructions, but GPT-5.5's forced V2 schema hides agent_type, model, and reasoning_effort. A generic task name does not activate the configured profile.

I have filed a focused issue about that precedence behavior: https://github.com/openai/codex/issues/31097

xsyetopz · 16 days ago

This remains operationally concerning in 0.142.5. The current binary still labels multi_agent_v2 as under development, and the collaborator guidance here says V2 is not recommended. However, the current GPT-5.5 model catalog sets multi_agent_version: v2, and Codex gives that model-level value precedence over features.multi_agent_v2=false. I reproduced the following: features list reports multi_agent_v2 ... false. A fresh GPT-5.5 thread nevertheless exposes the V2 task_name/fork_turns schema. Changing that thread to GPT-5.4 leaves it on V2. A fresh GPT-5.4 thread uses V1 and spawns a GPT-5.4-mini child successfully. * A V2 child test failed with Encrypted function output content could not be decrypted or decoded. This means users cannot both use GPT-5.5 and follow the recommendation to avoid V2. Shipping the implementation behind an under-development flag is understandable; model metadata silently overriding an explicit local disable is a different issue. It makes the public recommendation and the effective GPT-5.5 behavior inconsistent. It also makes the current custom-agent documentation inaccurate for GPT-5.5. The documented ~/.codex/agents/ profiles can pin model, reasoning effort, sandbox, and developer instructions, but GPT-5.5's forced V2 schema hides agent_type, model, and reasoning_effort. A generic task name does not activate the configured profile. I have filed a focused issue about that precedence behavior: #31097

They're not going to resolve this. Remember what one of their maintaners said?

Verbatim:

The multiagent v2 feature is still under development. We don't recommend its use, and we are not taking bug reports on this feature at this time.

@etraut-openai Y'people are seriously detached from reality. PLEASE, for the love of all things holy && unholy, TAKE F@CKING CARE OF YOUR OWN PRODUCT.

It's honestly disgusting to see the actual Codex team treat their own product like alpha/zeta-testing toy--IN PRODUCTION. Seriously? What the heck is wrong with you, huh? Y'do NOT deserve that title of being a part of OpenAI's team, really.

You, && the rest of the team that think under_developement == notToBeReportedAsBugsWhenExist, should be replaced by the community members that actually want a working, rock-solid product. Undeserved job. Please go get yourself checked out--PLEASE. THE COMMUNITY IS F@CKING TIRED.