Skip to content

Bug: openclaw status --usage --json hangs/fails from non-TTY subprocess in 2026.4.26 #74085

@DoubleAces

Description

@DoubleAces

After upgrading from 2026.4.23 to 2026.4.26, openclaw status --usage --json no longer works reliably when called from a non-TTY subprocess. It works from an interactive terminal, but hangs or fails with empty stdout/stderr when invoked from automation.

Environment

  • macOS arm64
  • OpenClaw 2026.4.26
  • Node v22.22.2
  • Provider: openai-codex OAuth
  • Regression from: 2026.4.23, where the same call worked from subprocess

Expected

openclaw status --usage --json should return machine-readable JSON from non-interactive subprocess contexts, as documented by the --json flag and as it did in 2026.4.23.

Actual

From a non-TTY subprocess:

  • no stdout
  • no stderr
  • exits 1 in some contexts, hangs until killed in others

From a real interactive terminal, the command works.
Other OpenClaw subcommands still work from subprocess.

Repro

node -e "const {spawnSync}=require('child_process'); const r=spawnSync('openclaw',['status','--usage','--json'],{encoding:'utf8',timeout:15000}); console.log({status:r.status,signal:r.signal,stdout:r.stdout,stderr:r.stderr,error:r.error?.message})"

Impact

This breaks automation that depends on OpenClaw usage/status snapshots, for example a Mission Control dashboard route that collects quota windows, session context load, task health, and gateway status.

A workaround is to run a separate user-context collector and read a cached JSON file, but the CLI regression means openclaw status --usage --json is currently not usable as a direct machine-readable subprocess command.

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleMarked as stale due to inactivity

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions