Summary
openclaw approvals get --gateway defaults to --timeout 10000. On a slower host, the command can time out while fetching config.get, then silently degrade the Effective Policy section to Config unavailable. even though gateway runtime, approvals snapshot, and real exec behavior are all healthy.
In practice this can look like an orion exec-approval regression, but it is actually a CLI timeout/reporting problem.
Environment
- OpenClaw:
2026.4.12
- Host: low-spec Debian box
- Channel/session context irrelevant; reproduced directly via CLI
Reproduction
Run:
openclaw approvals get --gateway
On this host it often returns output equivalent to:
gateway timeout after 10000msEffective Policy -> Config unavailable.
However the following are all healthy at the same time:
- runtime: running
- RPC probe: ok
And actual exec behavior is still correct.
If I rerun the same approvals command with a larger timeout:
openclaw approvals get --gateway --timeout 60000
then the command succeeds fully and Effective Policy renders normally.
On this machine, successful completion was around ~39.6s.
What seems to be happening
From the local installed CLI code path:
- approvals snapshot is fetched first
- then
config.get is fetched to render Effective Policy
- if that second call times out, the CLI catches it and reports only:
So the failure mode is misleading:
- approvals data itself is fine
- gateway config is actually available
- CLI default timeout is just too short for this path on some machines
Expected behavior
One or more of the following:
- Increase the default timeout for
openclaw approvals get --gateway
- Add a dedicated config/env override for this command's timeout
- Improve the error/reporting so timeout is distinguished from genuine config unavailability
- Optionally cache/reuse config more efficiently so Effective Policy rendering does not require such a slow second RPC on slower hosts
Actual behavior
Default command can falsely suggest a broken/missing policy state:
when the real issue is only CLI timeout.
Why this matters
This command is the main operator-facing inspection path for exec approvals. A misleading timeout here can cause users to think:
- agent exec approvals are broken
- gateway config is missing
- an upgrade regressed approval policy
when none of those are true.
Workaround
Use:
openclaw approvals get --gateway --timeout 60000
That restored the full Effective Policy output reliably on this host.
Summary
openclaw approvals get --gatewaydefaults to--timeout 10000. On a slower host, the command can time out while fetchingconfig.get, then silently degrade the Effective Policy section toConfig unavailable.even though gateway runtime, approvals snapshot, and real exec behavior are all healthy.In practice this can look like an
orionexec-approval regression, but it is actually a CLI timeout/reporting problem.Environment
2026.4.12Reproduction
Run:
On this host it often returns output equivalent to:
gateway timeout after 10000msEffective Policy -> Config unavailable.However the following are all healthy at the same time:
And actual exec behavior is still correct.
If I rerun the same approvals command with a larger timeout:
then the command succeeds fully and Effective Policy renders normally.
On this machine, successful completion was around ~39.6s.
What seems to be happening
From the local installed CLI code path:
config.getis fetched to render Effective PolicyConfig unavailable.So the failure mode is misleading:
Expected behavior
One or more of the following:
openclaw approvals get --gatewayActual behavior
Default command can falsely suggest a broken/missing policy state:
Config unavailable.when the real issue is only CLI timeout.
Why this matters
This command is the main operator-facing inspection path for exec approvals. A misleading timeout here can cause users to think:
when none of those are true.
Workaround
Use:
That restored the full Effective Policy output reliably on this host.