Bug type

Behavior bug (incorrect output/state without crash)

Summary

When monitoring subagents via subagents list, the runtime display shows 5-6x longer than actual wall-clock time. Final completion stats are correct, but interim status updates are inflated.

Steps to reproduce

1. Spawn a subagent with a task that takes ~5-15 minutes
2. Monitor status during execution via subagents list or status polling
3. Compare reported runtime with actual wall-clock time
4. Notice displayed time is 5-6x longer than reality

Expected behavior

Status updates should show accurate elapsed time matching wall-clock time. E.g., if a task takes 10 minutes, status should show "~1 min", "~2 min", ..., "~10 min" — not "~58 min".

Actual behavior

Status updates show wildly inflated times. Example from today:

• Wall-clock: 10 minutes (9:44 AM → 9:55 AM)
• Status updates: "~1 min" → "~58 min"
• Final stats: runtime 9m47s ✅ (correct)
• Interim updates: ❌ Wrong (5-6x inflated)

OpenClaw version

2026.3.11

Operating system

Linux 6.17.0-14-generic (x64) - Ubuntu

Install method

npm global install

Model

openai-codex/gpt-5.3-codex (but bug is model-agnostic)

Provider / routing chain

Default routing (not provider-specific)

Config file / key location

~/.openclaw/workspace/

Additional provider/model setup details

N/A - bug is in CLI status reporting, not model routing

Logs, screenshots, and evidence

[9:44 AM] Sub-agent spawned
[9:45 AM] ~1 minute in
[9:45 AM] ~2 minutes in
[9:46 AM] ~3 min → ~14.5 min (5 updates in 1 minute!)
[9:46 AM] ~5.5 min
[9:46 AM] ~7.5 min
[9:46 AM] ~9 min
[9:47 AM] ~10 min
...
[9:54 AM] ~58 minutes in
[9:55 AM] Sub-agent finished!

Impact and severity

Medium - doesn't break functionality, but erodes user trust and makes debugging difficult. Tasks appear 5-6x slower than reality, triggering false "something is stuck" alarms.

Additional information

Root Cause:
Files affected: <openclaw-install-path>/dist/reply-BCcP6j4h.js (lines 14083, 14095, 14109)

The runtimeMs value is calculated correctly but formatDurationCompact$1() appears to display it incorrectly.

Reporter Note:
I'm not a developer — I'm an OpenClaw user who encountered this bug during normal usage. This issue report was written with assistance from my AI agent, who helped document the problem, gather evidence, and locate the relevant code. The bug is real and reproducible on my end. Happy to provide additional context if needed.