openclaw - 💡(How to fix) Fix [Bug]: npm install fails silently on v2026.4.29 (macOS arm64) — exit 1 during @aws-sdk/@smithy dependency resolution [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

npm install of [email protected] fails silently with exit code 1 on macOS arm64 during @aws-sdk/@smithy dependency resolution; [email protected] installs fine on the same machine.

Steps to reproduce

1. On macOS Darwin 25.4.0 (arm64), Node v22.22.2, npm 11.13.0, with [email protected] currently installed at /opt/homebrew/lib/node_modules/openclaw.
2. Run: npm i -g openclaw@latest --no-fund --no-audit --loglevel verbose
3. npm fetches manifests for the full dependency tree (including @aws-sdk/client-bedrock-runtime and ~80 @smithy/* sub-packages), then exits with code 1 with no npm error line written to the log.
4. The same failure reproduces with: openclaw update, curl -fsSL https://openclaw.ai/install.sh | bash, npm i -g openclaw@latest --ignore-scripts, npm i -g openclaw@latest --maxsockets=2, and a clean local install (npm i openclaw@latest in a fresh /tmp directory).
5. Installing [email protected] with the same npm command succeeds. Installing other packages globally (e.g. npm i -g cowsay) also succeeds, ruling out a broken npm.
6. npm cache was cleaned (npm cache clean --force) and root-owned cache files were fixed (sudo chown -R 501:20 ~/.npm) — failure persists.

Expected behavior

npm i -g openclaw@latest should complete successfully and install version 2026.4.29, the same way it does for 2026.4.27 (currently installed and working) and the same way npm i -g cowsay works on the same machine.

Actual behavior

The install fails with exit code 1 but produces no npm error line in the log. The npm process appears to crash silently during dependency manifest resolution. The verbose log ends with the following lines (full log attached):

1078 silly packumentCache full:https://registry.npmjs.org/@smithy%2futil-config-provider set size:44068 disposed:false 1079 verbose cwd /Users/ws 1080 verbose os Darwin 25.4.0 1081 verbose node v22.22.2 1082 verbose npm v10.9.7 1083 verbose exit 1 1084 verbose code 1 1085 error A complete log of this run can be found in: /Users/ws/.npm/_logs/...

The crash consistently happens after fetching ~80 @smithy/* and @aws-sdk/* manifests (likely the @aws-sdk/client-bedrock-runtime subtree, possibly related to the new "Bedrock Opus 4.7 thinking parity" feature mentioned in the 2026.4.29 release notes).

Reproduces with: openclaw update, curl -fsSL https://openclaw.ai/install.sh | bash, npm i -g openclaw@latest, npm i -g openclaw@latest --ignore-scripts, npm i -g openclaw@latest --maxsockets=2, and a clean local install in a fresh /tmp directory. Same machine successfully installs [email protected] and cowsay. npm cache was cleaned and root-owned cache files were fixed via sudo chown -R 501:20 ~/.npm — failure persists. Tested with both npm 10.9.7 and npm 11.13.0.

OpenClaw version

2026.4.29 (target — failing to install). Currently installed: 2026.4.27 (working).

Operating system

macOS 15.4 (Darwin 25.4.0) arm64 — Apple Silicon

Install method

npm global (npm i -g openclaw@latest)

Model

N/A — install fails before any model is invoked.

Provider / routing chain

N/A — install fails before any provider is configured or invoked. The bug is in the npm install phase, not at runtime.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

**npm verbose log tail (last lines before silent crash):**


1057 silly fetch manifest @smithy/util-buffer-from@^4.2.2
1058 silly packumentCache full:https://registry.npmjs.org/@smithy%2futil-buffer-from cache-miss
...
1078 silly fetch manifest @smithy/util-buffer-from@^4.2.2
1079 silly packumentCache full:https://registry.npmjs.org/@smithy%2futil-buffer-from cache-miss
1080 http cache https://registry.npmjs.org/@smithy%2fsignature-v4 31ms (cache hit)
1081 silly packumentCache full:https://registry.npmjs.org/@smithy%2fsignature-v4 set size:229389 disposed:false
1082 silly packumentCache full:https://registry.npmjs.org/@smithy%2fsignature-v4 dispose
1083 verbose cwd /Users/ws
1084 verbose os Darwin 25.4.0
1085 verbose node v22.22.2
1086 verbose npm  v11.13.0
1087 verbose exit 1
1088 verbose code 1
1089 error A complete log of this run can be found in: /Users/ws/.npm/_logs/2026-05-02T04_33_56_568Z-debug-0.log


Note: there is **no `npm error` line** explaining the failure — npm exits silently with code 1 mid-resolution. The crash is reproducible at the same dependency resolution position across multiple runs.

**Resolved dependency tree at point of crash:**
- `[email protected]` requires `@mariozechner/[email protected]`
- which requires `@aws-sdk/client-bedrock-runtime@^3.1030.0` (resolves to 3.1041.0)
- which fans out into ~80 `@smithy/*` and `@aws-sdk/*` sub-packages
- npm crashes silently while fetching manifests in this subtree, consistently around `@smithy/util-buffer-from`, `@smithy/util-hex-encoding`, `@smithy/signature-v4`, etc.

**Reproduction across configurations (all fail with the same silent exit 1):**

| # | Command | Result |
|---|---|---|
| 1 | `openclaw update` | exit 1 |
| 2 | `curl -fsSL https://openclaw.ai/install.sh \| bash` | exit 1 |
| 3 | `npm i -g openclaw@latest --no-fund --no-audit` | exit 1 |
| 4 | `npm i -g openclaw@latest --ignore-scripts` | exit 1 |
| 5 | `npm i -g openclaw@latest --maxsockets=2` | exit 1 |
| 6 | Local install in fresh /tmp dir | exit 1 |
| 7 | After `sudo chown -R 501:20 ~/.npm` + `npm cache clean --force` | exit 1 |
| 8 | After upgrading npm 10.9.7 → 11.13.0 | exit 1 |

**Control tests (all succeed on the same machine):**
- `npm i -g cowsay` — works
- `npm i -g [email protected]` — works (currently installed and running)

**Hypothesis:** the `@aws-sdk/client-bedrock-runtime` subtree (likely tied to the new "Bedrock Opus 4.7 thinking parity" feature in 2026.4.29 release notes) introduces a dependency-graph state that causes npm's arborist to crash silently mid-resolution. The crash position is deterministic.

Full verbose npm log attached below./Users/ws/.npm/_logs/2026-05-02T04_33_56_568Z-debug-0.log

Impact and severity

Affected: All users on macOS arm64 attempting to upgrade to or freshly install [email protected] via npm. Likely also affects Linux/Windows depending on npm/node version, but only personally verified on macOS arm64.

Severity: Blocks upgrade — users on prior versions cannot move to 2026.4.29. New installs cannot complete at all. Existing installs (e.g. 2026.4.27) continue to work.

Frequency: Always reproducible on this machine — 8/8 install attempts failed with the same silent exit 1 across multiple npm/node configurations.

Consequence: Users are locked on the prior version (2026.4.27 in my case) and cannot access new features in 2026.4.29 (Bedrock Opus 4.7 thinking parity, NVIDIA provider, people-aware memory wiki, etc.) until the install regression is fixed. The silent failure mode (no npm error written) makes this hard to self-diagnose.

2026-05-02T04_33_56_568Z-debug-0.log

Additional information

Regression details:

• Last known good version: 2026.4.27 (currently installed and working on this machine)
• First known bad version: 2026.4.29
• 2026.4.28 not tested (skipped this version on my machine)

Likely root cause hypothesis: The 2026.4.29 release notes mention "Providers/Amazon Bedrock: expose the full Claude Opus 4.7 thinking profile (xhigh, adaptive, and max) for Bedrock model refs" and a refresh of the AWS SDK in workspace dependencies. The npm crash position is consistently inside the @aws-sdk/client-bedrock-runtime / @smithy/* manifest resolution phase, which strongly suggests the regression was introduced by this AWS SDK / Bedrock dependency change.

Workaround: Stay on [email protected] — it continues to install and run normally. Users already on 2026.4.27 are not impacted unless they attempt to upgrade.

Possibly related issue: #75717 reports a different but also macOS arm64 + 2026.4.29 specific breakage (TUI hang after upgrade due to stale dist files). That issue describes a post-install failure mode; this issue describes a pre-install failure mode. They may share a common root cause in the 2026.4.29 packaging / dependency update.