Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Yes

Summary

On 2026.7.1-beta.5 (also reproduced on 2026.6.11), when the parent session's agent runs on the codex agent runtime, a completed subagent's completion announce never starts — the task ledger records the task as completed, but no announce run, wake attempt, fallback, or warning appears in gateway logs and no summary is ever injected into the parent session; reproduced 3/3 on beta.5, while an openclaw-runtime agent in the same gateway process delivers the announce every time.

Steps to reproduce

1. Start a loopback gateway from the 2026.7.1-beta.5 source build: node dist/index.js gateway --port <p> --bind loopback --allow-unconfigured, token auth, with two agents on the same openai/gpt-5.5 model: rt-openclaw (default; agentRuntime openclaw) and rt-codex (agentRuntime codex; codex plugin enabled with appServer.mode: "yolo"), shared workspace, sandbox.mode: "off". Full config and env in "Additional provider/model setup details" below.
2. sessions.create a session for the codex-runtime agent (key agent:rt-codex:dashboard:<x>).
3. chat.send to that session: instruct the agent to call sessions_spawn once (child task: reply exactly <CHILD>), then call sessions_yield with message exactly <ACK>, and after the child completion arrives, write a parent summary containing <PARENT> and <CHILD>.
4. Watch tasks.list for the parent session and the parent session transcript for 180 s after the child's task reaches completed.
5. Control: repeat steps 2–4 with the rt-openclaw agent in the same gateway process.

Expected behavior

What the openclaw-runtime control agent does in the same gateway process and environment: after the child completes, the completion announce runs (visible as run announce:v1:agent:rt-openclaw:subagent:... in logs) — even when the requester session cannot be woken, it logs a warning and falls back to a requester-agent handoff, and the parent summary is injected into the parent session transcript within a few seconds (log excerpt in Logs below).

Actual behavior

For the codex-runtime agent: sessions_spawn and sessions_yield execute (tool events visible, <ACK> delivered), the child completes and its exact reply is produced, tasks.list shows the task completed with childSessionKey set — then nothing. No run announce:v1:agent:rt-codex:... line, no wake attempt, no fallback, no warning; the parent summary never appears in the parent session transcript within 180 s (test then tears the gateway down). Observed 3/3 on 2026.7.1-beta.5, with gateway logs inspected in 2 of those runs confirming zero announce runs for the codex parent. On 2026.6.11 the same scenario failed to deliver the parent summary in 2/2 runs (gateway logs were not inspected for announce lines on that version). The openclaw-runtime control delivered its announce in the same runs. Timestamped log excerpts below.

OpenClaw version

2026.7.1-beta.5 (b6387af), built from the release tag with pnpm 11.2.2. Also reproduced on 2026.6.11 (e085fa1).

Operating system

Debian 13 (trixie), Linux 6.12.57, x86_64. Node v22.22.0.

Install method

Source checkout of the release tag; pnpm install --frozen-lockfile && pnpm build; gateway launched directly via node dist/index.js gateway.

Model

openai/gpt-5.5

Provider / routing chain

openclaw -> api.openai.com (openai-responses). Parent agent turns execute on the codex app-server runtime (agentRuntime.id: "codex"); the control agent uses the default openclaw runtime with the identical model and provider.

Additional provider/model setup details

Gateway config (~/.openclaw/openclaw.json in an isolated HOME; token redacted):

{
  "gateway": {
    "port": "<p>",
    "auth": { "mode": "token", "token": "<redacted>" },
    "controlUi": { "enabled": false },
    "nodes": { "allowCommands": ["camera.snap", "camera.list", "action.perform", "action.list", "config.reload"] }
  },
  "plugins": {
    "allow": ["codex"],
    "entries": { "codex": { "enabled": true, "config": { "appServer": { "mode": "yolo" } } } }
  },
  "agents": {
    "defaults": {
      "workspace": "<workspace>",
      "skipBootstrap": true,
      "timeoutSeconds": 180,
      "model": { "primary": "openai/gpt-5.5" },
      "models": { "openai/gpt-5.5": { "agentRuntime": { "id": "openclaw" } } },
      "sandbox": { "mode": "off" }
    },
    "list": [
      { "id": "rt-openclaw", "default": true, "workspace": "<workspace>", "model": { "primary": "openai/gpt-5.5" }, "models": { "openai/gpt-5.5": { "agentRuntime": { "id": "openclaw" } } }, "sandbox": { "mode": "off" } },
      { "id": "rt-codex", "workspace": "<workspace>", "model": { "primary": "openai/gpt-5.5" }, "models": { "openai/gpt-5.5": { "agentRuntime": { "id": "codex" } } }, "sandbox": { "mode": "off" } }
    ]
  },
  "models": { "providers": { "openai": { "models": [ { "id": "gpt-5.5", "name": "Runtime Probe gpt-5.5" } ] } } }
}

Environment: the gateway ran in a test harness with OPENCLAW_TEST_MINIMAL_GATEWAY=1, VITEST=1, OPENCLAW_SKIP_BROWSER_CONTROL_SERVER=1, OPENCLAW_SKIP_GMAIL_WATCHER=1, OPENCLAW_SKIP_CANVAS_HOST=1, OPENCLAW_SKIP_CHANNELS=1, OPENCLAW_SKIP_CRON=1, OPENCLAW_BUNDLED_PLUGINS_DIR=<repo>/dist/extensions, isolated HOME, OPENCLAW_CONFIG_PATH, OPENCLAW_STATE_DIR. We have not reproduced on a stock (non-minimal) gateway; however, the openclaw-runtime control agent delivers its announce under this identical environment in the same gateway process, so the environment alone does not suppress announces.

Logs

codex-runtime parent (2026.7.1-beta.5) — child completes, then silence until teardown:

15:13:47.3   [agents/tool-policy] tool policy removed 9 tool(s) via subagent tools.deny ...
15:13:49.036 [agent/embedded] codex app-server one-shot cleanup retired shared client
15:13:49.041 CUT4-CODEX-1AC509-CHILD                  <- child's exact reply
15:13:49.043 [agents/agent-command] [agent] run d6060427-... ended with stopReason=stop
15:13:53.140 [agent/embedded] codex app-server turn released after terminal dynamic tool result
             (no further log lines for this session until SIGTERM ~3 minutes later)

openclaw-runtime control (same gateway process, minutes earlier) — announce runs and delivers, including a working could-not-wake fallback:

15:13:33.584 CUT4-OPENCLAW-58D537-CHILD
15:13:33.929 [warn] Active requester session could not be woken for subagent completion;
             falling back to requester-agent handoff: ... queue_message_failed
             reason=runtime_rejected ... active session ended before queued steering
             message was committed to the transcript
15:13:36.958 Parent summary: The child completed the requested exact reply,
             CUT4-OPENCLAW-58D537-CHILD. Parent marker: CUT4-OPENCLAW-58D537-PARENT.
15:13:36.961 [agents/agent-command] [agent] run announce:v1:agent:rt-openclaw:subagent:...
             ended with stopReason=stop

Screenshots, recordings, and evidence

NOT_ENOUGH_INFO

Impact and severity

• Affected: any Gateway client that surfaces subagent completions from the parent session transcript (chat UIs, voice clients) when the parent session's agent runs on the codex runtime.
• Severity: silent loss of the subagent's result — the task ledger says completed, but no completion ever reaches the parent conversation and no error is surfaced anywhere.
• Frequency: 3/3 on 2026.7.1-beta.5, 2/2 on 2026.6.11 in our environment (always, for this scenario).
• Consequence: orchestration results never reach the user; our client now re-prompts the parent session after observing ledger completion as a workaround, costing one extra model turn and ~20 s added latency per subagent completion.

Additional information

Regression status: NOT_ENOUGH_INFO — we did not test pristine 2026.5.28, so we cannot state a last known good version. One localizing observation (single run): the same scenario delivered the parent summary on a 2026.5.28 install whose codex extension carries local modifications to the app-server attempt-notification/turn-completion-release files (extensions/codex/src/app-server/attempt-notification-state.ts, attempt-notifications.ts, attempt-timeouts.ts, run-attempt.ts), consistent with the failure being in codex turn-completion release rather than the core announce flow.

Related but distinct open issues (all show the announce path actually running): #92076 (announce runs, fails on session write lock when requester inactive), #92116 (completion delivered but as ignorable passive context), #90925 (announce runs on wrong model route for Codex/OAuth).

Authorship disclosure: this issue was investigated and drafted by an AI agent (Claude, operated by the reporter) while validating a downstream OpenClaw client against 2026.7.1-beta.5; the human reporter reviewed it before filing. Coverage is limited to the scenario described above — we have not tested other channels, other models, or a stock (non-minimal) gateway. Filed via gh CLI, so the form's automatic bug label is absent.