Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Several openclaw <parent> commands exit with code 1 when invoked with no subcommand, while printing the same help-style content that openclaw <parent> --help prints (which exits 0). This breaks shell && chains, surfaces a misleading ELIFECYCLE Command failed with exit code 1. line under what looks like normal help output, and is inconsistent across the CLI surface — agents and sessions handle the bare form correctly (exit 0 with a default action), but memory, channels, plugins, approvals, devices, cron, and mcp all exit 1.

Steps to reproduce

1. Fresh checkout of openclaw at v2026.4.26 (commit cce0c28); run pnpm install && pnpm build on Node 22.22.2.
2. Run pnpm openclaw memory (or any of: channels, plugins, approvals, devices, cron, mcp) with no subcommand and no other args.
3. Observe ELIFECYCLE Command failed with exit code 1. after the help-style output.
4. Run echo $? — exit code is 1.
5. For comparison, run pnpm openclaw memory --help and echo $? — same output, exit code 0.
6. Confirm sibling parents handle it correctly: pnpm openclaw agents and pnpm openclaw sessions both exit 0.

Expected behavior

openclaw <parent> (no subcommand) should exit 0, matching two grounded references observed in the same CLI on the same build (v2026.4.26 / cce0c28):

1. openclaw <parent> --help — prints identical help-style content and exits 0. The bare form prints the same text but exits 1.
2. Sibling parent commands openclaw agents and openclaw sessions — print a sensible default listing for the bare form and exit 0. The seven affected parents differ only in lacking that default action.

Either of those is the known-good baseline; the affected parents should match.

Actual behavior

Bare-parent invocations print help-style content (subcommand list and a docs link) and then exit with code 1. Observed in the same shell on v2026.4.26 / cce0c28, Node 22.22.2:

$ pnpm openclaw memory ... (prints "openclaw memory status" example list, "Docs: https://docs.openclaw.ai/cli/memory") ELIFECYCLE Command failed with exit code 1. $ echo $? 1

Same pattern for channels, plugins, approvals, devices, cron, mcp:

$ for cmd in memory channels plugins approvals devices cron mcp agents sessions; do pnpm openclaw "$cmd" >/dev/null 2>&1; echo "$cmd -> $?" done memory -> 1 channels -> 1 plugins -> 1 approvals -> 1 devices -> 1 cron -> 1 mcp -> 1 agents -> 0 sessions -> 0

User-visible surface in pnpm: the trailing line ELIFECYCLE Command failed with exit code 1. appears under the help text, signalling failure even though the help output rendered normally.

OpenClaw version

2026.4.26

Operating system

Ubuntu 24.04.4

Install method

pnpm dev (source checkout from github.com/openclaw/openclaw; pnpm install + pnpm build; invoked via pnpm openclaw)

Model

anthropic/claude-opus-4-7

Provider / routing chain

N/A — no provider chain is involved. The bug is in the local CLI command tree (Commander default-action wiring); the affected commands return before any gateway, proxy, provider, or model router is contacted. Reproduces with no provider configured and no network access.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

=== Build under test (grounds version + commit) ===

$ pnpm openclaw --version
2026.4.26
$ git rev-parse --short HEAD
cce0c28
$ node --version
v22.22.2

=== Bare-parent vs --help exit code matrix (single shell session) ===

$ for cmd in memory channels plugins approvals devices cron mcp agents sessions; do
    pnpm openclaw "$cmd" >/dev/null 2>&1; echo "openclaw $cmd -> $?"
  done
openclaw memory -> 1
openclaw channels -> 1
openclaw plugins -> 1
openclaw approvals -> 1
openclaw devices -> 1
openclaw cron -> 1
openclaw mcp -> 1
openclaw agents -> 0
openclaw sessions -> 0

$ for cmd in memory channels plugins approvals devices cron mcp; do
    pnpm openclaw "$cmd" --help >/dev/null 2>&1; echo "openclaw $cmd --help -> $?"
  done
openclaw memory --help -> 0
openclaw channels --help -> 0
openclaw plugins --help -> 0
openclaw approvals --help -> 0
openclaw devices --help -> 0
openclaw cron --help -> 0
openclaw mcp --help -> 0

=== Sample bare-parent output (showing help-style content + ELIFECYCLE failure line) ===

$ pnpm openclaw memory
> [email protected] openclaw /home/orin/Gittensor/Test/openclaw
> node scripts/run-node.mjs memory

  openclaw memory status
    Show index and provider status.
  openclaw memory status --fix
    Repair stale recall locks and normalize promotion metadata.
  ... (truncated; full subcommand example list)
  openclaw memory status --json
    Output machine-readable JSON (good for scripts).

Docs: https://docs.openclaw.ai/cli/memory

 ELIFECYCLE  Command failed with exit code 1.

$ pnpm openclaw channels
... (subcommand list)
Docs: https://docs.openclaw.ai/cli/channels

 ELIFECYCLE  Command failed with exit code 1.

=== Counter-example: agents/sessions exit 0 with a sensible default action ===

$ pnpm openclaw agents
... (prints routing default + tip lines)
  Routing: default (no explicit rules)
$ echo $?
0

$ pnpm openclaw sessions
Sessions listed: 1
Kind   Key                        Age       Model           Tokens (ctx %)       Flags
direct agent:main:main            2m ago    claude-opus-4-7 35k/1049k (3%)       system id:bd65b76e-5383-4e24-9838-3ba4bce5ff87
$ echo $?
0

Impact and severity

Affected users/systems/channels:

• Every operator who invokes a parent CLI command without a subcommand to discover what's available — the canonical "what does this command do?" UX path.
• Every shell script, alias, or CI step that runs a bare parent (e.g. openclaw plugins to print a quick summary) and chains via && or relies on exit codes.
• Surface confirmed on Linux (Ubuntu 24.04 / Node 22.22.2 / pnpm 10.33.0); CLI surface is platform-agnostic so behavior is expected on macOS/Windows too, though only Linux was directly observed.

Severity:

• Annoying / DX paper cut. Misleads operators with ELIFECYCLE Command failed with exit code 1. after what looks like normal help output.
• Workflow-breaking for shell chains: any openclaw <parent> && <next> silently skips <next>. Direct evidence: bare-parent returns exit code 1, which short-circuits && chains by definition.
• No data risk, no security impact observed — affected commands return before any gateway/provider/network call.

Frequency:

• Always, deterministic. 7 of 9 parent commands tested reproduce the bug on every invocation in the same shell, with exit codes identical across repeated runs.

Consequence:

• Misleading failure signal during CLI exploration (new operators see "Command failed" under help text).
• Silent skips in &&-chained shell scripts and CI steps that include a bare parent for discovery or status.
• Inconsistent CLI surface between sibling parent commands (agents/sessions vs the seven affected) which costs operator trust and complicates documentation.
• No grounded evidence of missed messages, failed onboarding, or extra cost.

Additional information

• Regression status: unknown. I have not bisected. Only v2026.4.26 (commit cce0c28) was directly observed; last-known-good and first-known-bad versions were not measured. Do not classify as a regression without that evidence.

• Likely fix locus: the per-feature *-cli.ts files in src/cli/ and the parent-command builders under src/cli/program/. The two parents that work correctly (agents, sessions) appear to register their own default .action() that performs a sensible read-only listing; the seven affected parents do not, so Commander.js's built-in fallback prints help and exits non-zero. A single helper that registers .action(() => cmd.outputHelp()) on any parent without a custom action would normalize all of them.

• Suggested regression test: a table-driven test alongside src/cli/program/command-tree.test.ts / src/cli/program/help.test.ts that walks every registered parent in the program tree and asserts exitCode === 0 when invoked with no args. Locks the contract for any new parent group added later.

• Dedupe checked against the openclaw issue corpus on 2026-04-28: no existing open or closed issue matches this exact behavior. Closest related and distinct: #59449 (openclaw cron <subcommand> --help showed parent help instead of subcommand help — fixed and closed; different code path).

• Not exercised in this repro: provider auth (skipped because openclaw models auth login requires an interactive TTY in this environment). The bug is independent of provider state — the affected commands return before any model call.

• Reporter environment quirk worth noting (not the cause): the doctor-installed systemd user service openclaw-gateway.service had to be pointed at ~/.nvm/versions/node/v22.22.2/bin/node because system Node at /usr/bin/node is v20.20.2 (below the required ≥22.14). Doctor handled this automatically. Mentioned only so reviewers don't suspect a Node version mismatch — Node 22.22.2 was active for every reproduction above.