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

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

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.

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.

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

@etraut-openai

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?

@etraut-openai

@etraut-openai I filed #27205 for the issue that @xsyetopz mentioned. It makes 0.138.0 unusable (literally can't send any prompt) for me.

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

marked,same issue

docs(lazycodex): cite openai/codex#26753 as basis for multi_agent_v2 …

test(omo-codex): pin managed-comment annotation on the multi_agent_v2…

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

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...

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

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?

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

fix(sandbox): extra-repo tools in agent TOOL_DIRS; disable codex mult…

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.

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.

Same issue for me on 0.125.0

Same issue for me on 0.125.0

The same configuration worked on codex cli version 0.137.0.

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

@etraut-openai

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.

responses: v1-surface ultra delegation prompt + encrypted-slot saniti…

feat: routed compaction for third-party providers (codex-router kcr1 …

responses: v1-surface ultra delegation prompt + encrypted-slot saniti…

Navigation Menu

Repository navigation

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

What happened?

Minimal repro

Actual behavior

Expected behavior

Workaround

Suspected regression

Environment

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What happened?

Minimal repro

Actual behavior

Expected behavior

Workaround

Suspected regression

Environment

Activity

WindLucker commented on Jun 6, 2026

etraut-openai commented on Jun 6, 2026

lovingfish commented on Jun 6, 2026

xsyetopz commented on Jun 9, 2026

cowwoc commented on Jun 9, 2026

agirardeau commented on Jun 10, 2026

jiabaogithub commented on Jun 10, 2026

3 remaining items

septrcode commented on Jun 11, 2026

xsyetopz commented on Jun 11, 2026

septrcode commented on Jun 11, 2026

xsyetopz commented on Jun 11, 2026

septrcode commented on Jun 11, 2026

smashah commented on Jun 12, 2026

ignatremizov commented on Jun 13, 2026

theTrident commented on Jun 18, 2026

theTrident commented on Jun 18, 2026

Alek2077 commented on Jul 4, 2026

xsyetopz commented on Jul 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions