#codex sessions spawn

1 messages · Page 1 of 1 (latest)

bitter fox
#

codex harness does not expose sessions_spawn like pi harness did. So spawning a sub agent, freeing up your main agent to chat and do other things, and getting a ping back to main agent when the work is done... not a thing right now on 5.12 public release......is this normal and we should ask the agent to change it behavior around hand offs or is this a possible regression with version 5.12

tiny reefBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

modern mantleBOT
# bitter fox codex harness does not expose sessions_spawn like pi harness did. So spawning a ...

I checked current source and the v2026.5.12 tag.

Short version: it should not be “Pi-only” conceptually, but Codex exposes it differently.

In v2026.5.12, the Codex app-server harness filters out Codex-native duplicate workspace tools like read/write/exec/apply_patch/update_plan, but it does not exclude sessions_spawn or subagents. The Codex harness docs for 5.12 say remaining OpenClaw integration tools, including sessions tools, are exposed through Codex dynamic tool search under the openclaw namespace, not necessarily as the same obvious top-level tool list Pi showed.

So:

  • If you only mean “I don’t see sessions_spawn in the visible/top-level Codex tool list like Pi”, that’s probably expected for Codex dynamic tools.
  • If Codex genuinely cannot discover/call it at all, that smells like a bug/regression or config gating, not expected behavior.

Things I’d check:

  1. openclaw --version to confirm exact build.
  2. /status to confirm the runner/harness and whether tools are disabled/restricted.
  3. Config for tools.allow, plugins.entries.codex.config.codexDynamicToolsExclude, or a custom toolsAllow path that might accidentally omit sessions_spawn.
  4. Try plugins.entries.codex.config.codexDynamicToolsLoading: "direct" as a diagnostic. If it appears in direct mode, the issue is tool-search/discovery UX rather than the underlying tool being absent.
  5. As a user-side workaround, /subagents spawn <agentId> <task> should start a background subagent and announce back when done.