openclaw - 💡(How to fix) Fix Subagent/Codex orchestration chain is not capability-correct or reliably observable

Summary

We are seeing several previously reported subagent/Codex failures as one connected reliability problem: the parent agent can start work, but the Codex/subagent orchestration chain is not consistently inspectable, controllable, or capability-correct.

From an agent/user point of view this means: background work appears accepted, but the parent cannot reliably know whether the child is visible, alive, using the intended model/capabilities, or actually able to run the requested tools.

This is starting to break normal Codex-powered workflows such as startup patrols, background docs-health checks, cron/isolated command jobs, and multi-agent delegation.

Related issues / PRs already filed

• #75593 — /subagents list still empty after spawn on v2026.4.29
• #75679 — PR to canonicalize subagent list requester keys; still open and needs real behavior proof / merge
• #82744 — thinking capability check uses literal provider/model instead of effective routed target; closed, but the same capability mismatch is now visible in subagent spawn/runtime paths
• #84141 — isolated cron agent turns omit requested exec despite toolsAllow
• #84053 — background subagent completion notifications dropped silently; closed, but this remains part of the same reliability surface from the operator point of view
• #84270 / #84272 — completion announce retry/accounting/logging problems around subagent completion delivery
• #83994 — cron isolated session hotfix suggestions around path/cache/timing/delivery/idempotency

Fresh reproduction: startup docs-health patrol subagent cannot start because thinking is not filtered for the routed subagent target

Environment:

• OpenClaw: 2026.5.18 (50a2481)
• Parent session model: openai-codex/gpt-5.5
• Channel: Telegram direct
• Startup flow: parent session runs startup launcher, which prints a docs-health patrol sessions_spawn payload

Startup asks the parent to spawn a background docs-health patrol subagent. The payload is otherwise valid and accepted by sessions_spawn.

Observed failure with the default subagent model:

failed: Error: Thinking level "high" is not supported for openai/gpt-5.4. Use one of: off.

Then we explicitly tested an OpenAI Codex subagent:

{
  "model": "openai-codex/gpt-5.5",
  "thinking": "high"
}

That also failed with the same capability class:

Thinking level "high" is not supported ... Use one of: off.

Workaround:

{
  "thinking": "off"
}

With thinking: "off", the docs-health patrol subagent can start and complete/skip normally.

Why this is not just one bad payload

The parent session itself is running on openai-codex/gpt-5.5 with thinking enabled and working. The failure only appears when the work moves into the subagent/isolated runtime path.

So the problem is not simply "this model can never think". The problem is that subagent spawn/runtime capability validation is not aligned with the effective routed target and runtime constraints. It accepts or inherits a thinking level that the actual subagent route later rejects, causing accepted background work to die before reaching the task body.

This is similar in shape to #82744, but on the subagent path rather than the interactive /think directive path.

Why this matters

This breaks the basic Codex delegation loop:

1. Parent decides to delegate background work.
2. sessions_spawn returns accepted.
3. Child fails at runtime preflight/capability validation before doing any work.
4. Parent must inspect subagent state manually to notice.
5. If list/control/completion delivery is also flaky, the parent may believe background work is still pending or completed when it never actually started.

For agent-first workflows, this is serious because the whole point of subagents is to let the parent safely delegate and later inspect/control/receive completion. Right now the chain has multiple weak links:

• visibility: child may not appear in /subagents list (#75593 / #75679)
• capability: thinking validation can reject the routed subagent target (#82744-adjacent, fresh repro above)
• execution: isolated cron/subagent jobs may not receive requested tools (#84141)
• completion: child completion can be dropped/retried/misaccounted (#84053 / #84270 / #84272)
• observability: failures can look like accepted background work until a human asks what happened

Expected behavior

For any sessions_spawn / subagent run:

1. Capability validation should happen before returning accepted, using the same effective routed target that will actually serve the child turn.
2. If a requested thinking level is unsupported for that child runtime, either:
   • reject the spawn immediately with a clear preflight error, or
   • safely remap to a supported level if policy says that is acceptable, and report the remap.
3. /subagents list should reliably show active/recent children from the requester session.
4. Required tools from toolsAllow should be hydrated or fail loudly before the model turn.
5. Completion/failure should be delivered/accounted exactly once, with enough logging to diagnose delivery/runtime failures.

Actual behavior

The subagent can be accepted, then fail immediately because the child runtime rejects the inherited/requested thinking level:

Thinking level "high" is not supported ... Use one of: off.

Manual workaround is to add:

"thinking": "off"

to lightweight background subagent payloads.

That workaround is not enough for the platform: agents should not need to know which hidden routed subagent target supports which thinking level before every spawn.

Suggested fix direction

A robust fix probably needs a single preflight/resolution layer for subagent/isolated agent turns:

• Resolve the effective model/provider/runtime for the child before accepting the run.
• Validate thinking against that effective child target, not the parent session or literal configured name.
• Apply/remap/reject deterministically before returning accepted.
• Validate toolsAllow against the hydrated child tool set before invoking the model.
• Store requester/controller keys in a canonical form so list/control always sees the run.
• Persist a terminal child state and last error even when model startup/capability validation fails before user-visible output.

Current local workaround

For now we will patch our startup/docs-health patrol payloads to include:

"thinking": "off"

This avoids the startup patrol failure, but it is a local workaround. The platform-level issue remains: subagent/Codex routing needs to be capability-correct and observable end-to-end.