Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Summary

I hit two problems on a Linux git install of OpenClaw:

1. openclaw update failed with preflight-no-good-commit.
2. Host exec works, but auto-exec / approval behavior appears inconsistent:
   • harmless commands were blocked with Blocked by allowlist. Need approval to proceed.
   • no usable approval popup/UI appeared
   • /approve ... failed with unknown or expired approval id
   • manual allowlisting of binaries made the same commands succeed

This suggests:

• the updater is hiding the actionable dependency-install reason behind a generic preflight error
• the exec engine itself works, but the approval / allowlist / auto-exec flow is broken or inconsistent

Steps to reproduce

A. Update failure

1. Run:

   openclaw update

2. Observe the updater fetch latest changes and iterate through candidate commits.
3. Observe every candidate fail at preflight deps install.
4. Observe final result:
   • Update Result: ERROR
   • Reason: preflight-no-good-commit

B. Exec approval / auto-exec issue

1. In chat, ask OpenClaw to run:

   echo OPENCLAW_EXEC_OK

2. Observe reply:

   Blocked by allowlist. Need approval to proceed.

3. Observe no usable approval popup/UI appears.
4. Try the suggested approval path in chat:

   /approve allow-once echo OPENCLAW_EXEC_OK

5. Observe error:

   Failed to submit approval: GatewayClientRequestError: unknown or expired approval id

6. Manually allowlist the binary:

   openclaw approvals allowlist add "/usr/bin/echo"

7. Retry the same exec request in chat.
8. Observe success:

   OPENCLAW_EXEC_OK

9. Repeat with another harmless binary:

   openclaw approvals allowlist add "/usr/bin/date"

10. Ask OpenClaw to run:

    date

11. Observe success, e.g.:

    Wed Apr 1 03:36:30 CST 2026

Expected behavior

Update

openclaw update should either:

• complete successfully, or
• report the real blocking reason clearly if preflight dependency install fails, instead of only returning generic preflight-no-good-commit. [web:170]

Exec

Given the displayed approvals/defaults state, harmless commands should either:

• run automatically if policy is permissive, or
• produce a working approval flow with a valid pending approval id and usable approval UI. Exec approvals are documented to depend on policy + allowlist + optional user approval, and /approve is supposed to act on a pending approval id. [web:592]

Actual behavior

Update

• openclaw update failed after checking multiple candidate commits.
• Every candidate failed at preflight deps install.
• Final result:
  • Update Result: ERROR
  • Reason: preflight-no-good-commit

Exec

• Simple harmless commands were blocked by allowlist.
• No usable approval popup/UI appeared.
• Manual /approve ... path failed with:
  • unknown or expired approval id
• After manual allowlisting of /usr/bin/echo and /usr/bin/date, the same commands succeeded.

This strongly suggests the exec engine itself is fine, but the approval / allowlist / auto-exec behavior is inconsistent or broken. Exec approvals are documented to return an approval id when a prompt is required, and pending approvals expire after 30 minutes by default, so an immediate "unknown or expired approval id" is unexpected here. [web:592]

OpenClaw version

2026.3.31-beta.1

Operating system

Linux Ubuntu 24.04.4 LTS

Install method

git checkout

Model

claude-haiku-4-5-20251001, minimax-m2.5, claude-sonnet-4-6

Provider / routing chain

OpenClaw CLI/App -> OpenClaw Gateway -> 3rd party proxy -> OpenAI-compatible endpoint

Additional provider/model setup details

No response

Logs, screenshots, and evidence

## Logs

### Update output


◇  ✓ Fetching latest changes
◇  ✓ Resolving upstream commit
◇  ✓ Enumerating candidate commits
│  ✓ Working directory is clean
◇  ✓ Preparing preflight worktree
◇  ✓ preflight checkout (cc278a76)
◇  ✗ preflight deps install (cc278a76)
◇  ✓ preflight checkout (a23b4dd5)
◇  ✗ preflight deps install (a23b4dd5)
...
Update Result: ERROR
Reason: preflight-no-good-commit
Before: 2026.3.31-beta.1


### Manual install output showing actionable cause


pnpm install
ERR_PNPM_NO_MATURE_MATCHING_VERSION
Version 0.43.0 of @oxfmt/binding-linux-arm64-gnu does not meet the minimumReleaseAge constraint


pnpm documents `minimumReleaseAge` and `minimumReleaseAgeExclude` as package-age security controls, so this looks like the real reason preflight deps install could not complete. [page:2]

### Approval / exec outputs


Blocked by allowlist. Need approval to proceed.



/approve allow-once echo OPENCLAW_EXEC_OK
❌ Failed to submit approval: GatewayClientRequestError: unknown or expired approval id



openclaw approvals allowlist add "/usr/bin/echo"
...
Allowlist:
│ local │ * │ /usr/bin/echo │ just now │



OPENCLAW_EXEC_OK



openclaw approvals allowlist add "/usr/bin/date"



Wed Apr 1 03:36:30 CST 2026


### Additional noisy warning

This warning appeared repeatedly across commands:


Config was last written by a newer OpenClaw (2026.3.31); current version is 2026.3.31-beta.1.

Impact and severity

No response

Additional information

Workaround

Update workaround

I was able to recover the repo manually with:

git fetch origin
git reset --hard origin/main

Then I verified the gateway was still healthy and usable.

Exec workaround

I was able to make harmless commands work by manually allowlisting resolved executable paths:

openclaw approvals allowlist add "/usr/bin/echo"
openclaw approvals allowlist add "/usr/bin/date"

After that, echo OPENCLAW_EXEC_OK and date both worked from chat.

This workaround confirms that host exec itself works, and the issue is likely in approval resolution, allowlist UX, or policy application rather than command execution. OpenClaw’s exec docs say allowlist mode matches resolved executable paths, which matches this behavior. [web:615][web:599]

Questions for maintainers

1. Should openclaw update surface pnpm minimumReleaseAge failures directly instead of only returning preflight-no-good-commit? [web:170][page:2]
2. Why does the chat exec path behave like allowlist-gated approval flow when the displayed approvals/defaults state looked permissive?
3. Why is there no usable approval UI in this case?
4. Why does /approve fail immediately with unknown or expired approval id instead of resolving the pending request? [web:592]