openclaw - 💡(How to fix) Fix /subagents log rejects the short `run` id surfaced by the spawn reply

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

/subagents action:spawn hands back a short run id (e.g. c186feb7); /subagents action:log target:c186feb7 rejects it as Unknown — operators must do an extra /subagents list round-trip to translate the run id into the #index form the log resolver accepts.

Error Message

  • Only change (b): still helpful, but operators who pasted the short run id (the natural read of the spawn reply) would still see Unknown subagent id. The error → correct-command round-trip stays in the loop.

Root Cause

/subagents action:spawn hands back a short run id (e.g. c186feb7); /subagents action:log target:c186feb7 rejects it as Unknown — operators must do an extra /subagents list round-trip to translate the run id into the #index form the log resolver accepts.

Fix Action

Fix / Workaround

  • Affected: every operator who runs /subagents action:spawn followed by /subagents action:log. In our case this is monitoring multi-hour pilot runs in Discord DMs with an OpenClaw bot.
  • Severity: annoying, blocks-workflow-momentarily, not a data risk. Each monitoring loop costs an extra /subagents list slash-command round-trip plus an operator context-switch to read the index column.
  • Frequency: always (every spawn → log sequence).
  • Consequence: wasted operator turns + the spawn reply's run id reads as a dead-letter token until you've memorised that it isn't the one to paste. New operators learn the workaround once and then carry the friction.

Filed by an external user against an OpenClaw deployment. Repro path is observed; the fix sketch is hypothesised from external behaviour, not from inspecting the runtime source — file paths in the proposal are best-guess (openclaw/runtime/subagents/log.ts, …/spawn.ts, …/resolver.ts) and will need confirmation by a maintainer against repo HEAD before any patch lands.

Code Example

function resolveSubagentTarget(input, session) {
  if (input.startsWith("#")) return resolveByIndex(input.slice(1), session);
  if (input.startsWith("agent:") && input.includes(":subagent:")) {
    return resolveBySessionKey(input);
  }
  // NEW — short run id (matches the format the spawn reply hands back).
  if (/^[0-9a-f]{8}$/.test(input)) {
    const hit = session.recentRuns.find(r => r.runId.startsWith(input));
    if (hit) return hit;
  }
  return resolveByRunId(input); // existing fallback for full UUID
}
RAW_BUFFERClick to expand / collapse

Summary

/subagents action:spawn hands back a short run id (e.g. c186feb7); /subagents action:log target:c186feb7 rejects it as Unknown — operators must do an extra /subagents list round-trip to translate the run id into the #index form the log resolver accepts.

Problem to solve

Every operator monitoring a long-running subagent pays an extra /subagents list call between spawn and log. The id the spawn reply hands back is not an id the log subcommand accepts, even though both ids point at the same run.

The log resolver currently accepts three forms:

  • #<index> (1-based position in the current session's active list)
  • Full session key like agent:<id>:subagent:<uuid>
  • Internal subagent id (not surfaced in chat)

The short run id from the spawn reply isn't a key the resolver indexes against, so /subagents log target:c186feb7 returns ⚠️ Unknown subagent id: c186feb7. Bare numeric indexes (target:1) are also rejected — only target:#1 works — so operators who skim the reply line and try the obvious shapes hit two failures before finding the working form.

This is a UX bug, not a correctness bug, but it shows up in every single monitoring loop.

Proposed solution

Two additive changes; either alone helps, both together close the gap. Neither breaks the existing #N or full-session-key paths.

(a) log resolver should accept the short run id

In the /subagents log handler (and ideally /subagents info | send | steer | kill for symmetry):

function resolveSubagentTarget(input, session) {
  if (input.startsWith("#")) return resolveByIndex(input.slice(1), session);
  if (input.startsWith("agent:") && input.includes(":subagent:")) {
    return resolveBySessionKey(input);
  }
  // NEW — short run id (matches the format the spawn reply hands back).
  if (/^[0-9a-f]{8}$/.test(input)) {
    const hit = session.recentRuns.find(r => r.runId.startsWith(input));
    if (hit) return hit;
  }
  return resolveByRunId(input); // existing fallback for full UUID
}

session.recentRuns already exists — /subagents list exposes "recent subagents (last 30m)" so the registry is in scope.

(b) Spawn reply should surface the #index and a copy-paste-ready command

Current reply:

Spawned subagent director (session agent:director:subagent:8ce91d2f-…, run c186feb7).

Proposed reply:

Spawned subagent #1 director (run c186feb7, session agent:director:subagent:8ce91d2f-…). Monitor: /subagents log #1 or /subagents log c186feb7 (after fix). Kill: /subagents kill #1.

The second line gives the operator the next command without forcing a list call first.

Alternatives considered

  • Only change (b): still helpful, but operators who pasted the short run id (the natural read of the spawn reply) would still see Unknown subagent id. The error → correct-command round-trip stays in the loop.
  • Only change (a): removes the friction, but operators have to know to try the short run id rather than reading it from the reply. (a) without (b) is partial UX.
  • Document the existing #N form harder in the spawn reply text only: doesn't help — the operator still needs /subagents list first to discover the index.
  • Leave as-is and document the gotcha: what we did locally (added a note to our slash-command spec), but every new operator hits it once.

Both (a) and (b) are additive — no existing call shape changes behaviour.

Impact

  • Affected: every operator who runs /subagents action:spawn followed by /subagents action:log. In our case this is monitoring multi-hour pilot runs in Discord DMs with an OpenClaw bot.
  • Severity: annoying, blocks-workflow-momentarily, not a data risk. Each monitoring loop costs an extra /subagents list slash-command round-trip plus an operator context-switch to read the index column.
  • Frequency: always (every spawn → log sequence).
  • Consequence: wasted operator turns + the spawn reply's run id reads as a dead-letter token until you've memorised that it isn't the one to paste. New operators learn the workaround once and then carry the friction.

Evidence/examples

Reproduced on 2026-05-27 in a Discord DM with our director agent:

  1. /subagents action:spawn target:director value:Half-factory pilot run …
  2. Bot replies (ephemeral): Spawned subagent director (session agent:director:subagent:8ce91d2f-7cc1-4873-a9d7-f986dcd66d00, run c186feb7).
  3. /subagents action:log target:c186feb7⚠️ Unknown subagent id: c186feb7
  4. /subagents action:log target:1📄 Usage: /subagents log <id|#> [limit]
  5. /subagents action:log target:#1 → returns the trajectory (works).
  6. /subagents action:log target:agent:director:subagent:8ce91d2f-7cc1-4873-a9d7-f986dcd66d00 → also works.

The only working forms are #N (after a prior /subagents action:list) or the full session key. Both add friction relative to the short run id that the spawn reply itself surfaces.

Additional information

Filed by an external user against an OpenClaw deployment. Repro path is observed; the fix sketch is hypothesised from external behaviour, not from inspecting the runtime source — file paths in the proposal are best-guess (openclaw/runtime/subagents/log.ts, …/spawn.ts, …/resolver.ts) and will need confirmation by a maintainer against repo HEAD before any patch lands.

The same resolver fix would benefit /subagents info | send | steer | kill for symmetry. Listed in (a) above.

Happy to refine the title or break this into separate issues (one for the resolver, one for the spawn-reply text) if maintainers prefer.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING