Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: openclaw status --usage --json hangs/fails from non-TTY subprocess in 2026.4.26 [1 pull requests, 1 comments, 2 participants]

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…
GitHub stats
openclaw/openclaw#74085•Fetched 2026-04-30 06:28:43
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
DoubleAcesDoubleAces
Participants
clawsweeper[bot]clawsweeper[bot]DoubleAcesDoubleAces
Timeline (top)
cross-referenced ×3commented ×1referenced ×1

Error Message

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})"

Fix Action

Fix / Workaround

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.

PR fix notes

PR #74185: fix(infra): wrap provider auth resolution in timeout for status --usage --json

Description (problem / solution / changelog)

Summary

  • Wraps resolveProviderAuths() in the existing withTimeout helper so auth resolution (OAuth token refresh, plugin auth hooks, secret exec resolvers) cannot hang indefinitely
  • Returns empty providers on auth timeout instead of blocking forever, allowing the JSON command to complete

Problem

openclaw status --usage --json hangs when called from a non-TTY subprocess (regression from 2026.4.23 to 2026.4.26). The individual provider usage fetches are bounded by withTimeout, but resolveProviderAuths() — which iterates sequentially over 7 providers calling plugin auth hooks, OAuth token refresh, and secret ref resolvers — had no timeout boundary. In a non-TTY subprocess, any of these can block indefinitely.

Changes

src/infra/provider-usage.load.ts

  • Wrapped the resolveProviderAuths() call at line 94 in withTimeout(…, timeoutMs, []) using the same timeout budget as the fetch phase
  • On timeout, returns [] (empty auths) which causes loadProviderUsageSummary to return { providers: [] } instead of hanging

src/infra/provider-usage.load.test.ts

  • Added mock for resolveProviderAuths to support testing the timeout path
  • Added test: "returns empty providers when auth resolution exceeds timeout" — mocks auth resolution as a promise that never settles, verifies the function resolves within the timeout

Fixes #74085

Changed files

  • src/infra/provider-usage.load.test.ts (modified, +39/-0)
  • src/infra/provider-usage.load.ts (modified, +9/-1)

Code Example

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})"
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The issue can be mitigated by investigating the differences in behavior between interactive and non-interactive subprocess contexts, potentially related to TTY or output handling.

Guidance

  • Investigate how openclaw status --usage --json handles output and errors in non-TTY subprocess contexts, comparing it to its behavior in interactive terminals.
  • Use the provided repro script to test and debug the command's behavior, focusing on the stdout, stderr, and exit status.
  • Consider modifying the subprocess invocation to simulate a TTY or adjust output handling to see if it resolves the issue.
  • Review the changes between OpenClaw versions 2026.4.23 and 2026.4.26 to identify potential causes for the regression.

Example

No specific code example is provided due to the need for further investigation into the openclaw command's internal handling of subprocess contexts.

Notes

The issue seems to be specific to the openclaw status --usage --json command and its interaction with non-TTY subprocesses, suggesting a potential issue with output handling or error reporting in this context.

Recommendation

Apply a workaround, such as running a separate user-context collector and reading a cached JSON file, until the root cause of the regression can be identified and addressed. This approach allows for continued automation functionality while the openclaw command issue is resolved.

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…
#API middleware#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Bug: openclaw status --usage --json hangs/fails from non-TTY subprocess in 2026.4.26 [1 pull requests, 1 comments, 2 participants]