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
#codex sessions spawn
1 messages · Page 1 of 1 (latest)
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_spawnin 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:
openclaw --versionto confirm exact build./statusto confirm the runner/harness and whether tools are disabled/restricted.- Config for
tools.allow,plugins.entries.codex.config.codexDynamicToolsExclude, or a customtoolsAllowpath that might accidentally omitsessions_spawn. - 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. - As a user-side workaround,
/subagents spawn <agentId> <task>should start a background subagent and announce back when done.