PR #66239: fix(cli): harden approvals get timeout handling

• Repository: openclaw/openclaw
• Author: neeravmakwana
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/66239

Description (problem / solution / changelog)

Summary

• Problem: openclaw approvals get --gateway inherited a 10s CLI timeout and could silently downgrade a config.get timeout into Config unavailable. even when the approvals snapshot itself succeeded.
• Why it matters: on slower hosts this makes healthy exec approval state look broken or missing to operators.
• What changed: approvals get now defaults to a 60s gateway timeout, preserves the approvals snapshot output, and reports config-load timeouts explicitly; the focused CLI regression test and changelog were updated too.
• What did NOT change (scope boundary): this does not change gateway RPC semantics or the underlying approval policy calculation.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #66234
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: approvals get used the generic nodesCallOpts 10s timeout even though the command does multiple serial RPCs (exec.approvals.get or exec.approvals.node.get, then config.get).
• Missing detection / guardrail: config.get failures were collapsed to null, so timeouts and genuine config unavailability both rendered the same Config unavailable. note.
• Contributing context (if known): the reported slow host completed successfully once the timeout was raised.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cli/exec-approvals-cli.test.ts
• Scenario the test should lock in: approvals get --gateway uses the longer default timeout, and an explicit config.get timeout renders a timeout-specific Effective Policy note instead of a generic unavailability message.
• Why this is the smallest reliable guardrail: the bug lives in CLI option defaults and CLI-side degradation/reporting, so the focused command test covers the exact decision points without requiring a live slow host.
• Existing test that already covers this (if any): the file already covered the generic config.get-failure fallback path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw approvals get now defaults to a 60s gateway timeout instead of inheriting the generic 10s node CLI timeout.
• When the follow-up config.get call times out, Effective Policy now reports that timeout explicitly and suggests rerunning with a higher --timeout.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS 26.0 (Darwin 25.3.0)
• Runtime/container: local repo checkout
• Model/provider: N/A
• Integration/channel (if any): gateway-mode CLI
• Relevant config (redacted): N/A

Steps

1. Reproduce the code path for openclaw approvals get --gateway on HEAD.
2. Run pnpm test src/cli/exec-approvals-cli.test.ts.
3. Verify the command now uses the longer default timeout and that an explicit timeout failure renders the timeout-specific note.

Expected

• Healthy approvals snapshots on slow hosts should no longer misleadingly degrade to Config unavailable. under the default command timeout.
• If config loading still times out, the CLI should say that it timed out.

Actual

• The CLI now keeps the approvals snapshot output, defaults the command to a higher timeout budget, and distinguishes timeouts from genuine config unavailability.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: inspected the exact approvals get CLI path; ran pnpm test src/cli/exec-approvals-cli.test.ts; the scoped commit hook also passed the repo pnpm check lane.
• Edge cases checked: explicit --timeout 10000 still yields a timeout-specific Effective Policy note; non-timeout config failures still preserve the generic unavailability fallback.
• What you did not verify: a live reproduction against a remote slow-host gateway.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: operators may wait longer before seeing a timeout if the gateway is genuinely stalled.
  • Mitigation: --timeout remains user-configurable, and the degraded note now explains that the failure was a timeout.

Disclosure

• AI-assisted: Yes
• Testing level: focused local test plus repo hook verification (pnpm check)

Made with Cursor

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/cli/exec-approvals-cli.test.ts (modified, +51/-6)
• src/cli/exec-approvals-cli.ts (modified, +36/-16)