issue update

[strong kindle]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[uncut shell]

That line is the build script heartbeat, not the actual error yet: tsdown is still running but has been quiet for 30s. On a slower Mac mini it can legitimately sit there for a bit, but the useful next step is to confirm whether it is working or wedged.

First, please paste these versions:

openclaw --version
node --version
pnpm --version
git rev-parse --short HEAD

One thing I already notice: your output shows pnpm v11.1.0, but the repo currently pins pnpm@10.33.0 and requires Node >=22.14.0. I’d normalize that before retrying:

cd ~/Bureau/openclaw
corepack enable

corepack prepare pnpm@10.33.0 --activate
pnpm --version
pnpm install
OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 pnpm build

If it still repeats the heartbeat for several minutes, check whether the tsdown pid is consuming CPU:

ps -p 2289798 -o pid,etime,%cpu,%mem,command
pgrep -fl tsdown

If CPU is near 0% for a long time, grab a short macOS sample and share the tail:

sample 2289798 5 -file /tmp/openclaw-tsdown-sample.txt
tail -80 /tmp/openclaw-tsdown-sample.txt

Docs refs: https://docs.openclaw.ai/help/faq and source setup at https://docs.openclaw.ai/start/setup

[versed galleon]

its mac mini with linux. the cpu is 999% but eat all the ram

[uncut shell]

999% CPU means tsdown is working, not idle. The bad part is the RAM pressure: if Linux starts swapping hard, the build can look “alive” forever while making almost no progress.

I’d stop it with Ctrl-C if the machine is thrashing, then retry with a cleaner baseline and capture memory usage:

cd ~/Bureau/openclaw
corepack enable
corepack prepare pnpm@10.33.0 --activate

node --version
pnpm --version
free -h
/usr/bin/time -v env OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 pnpm build

If RAM is small, add/enable swap before building. On Linux, check first:

[uncut shell]

swapon --show
free -h

Also: if this is just to use OpenClaw rather than hack on the source, the git/source build is the heaviest path. Send openclaw --version, node --version, pnpm --version, RAM size from free -h, and the final /usr/bin/time -v output if it fails or gets killed. That will tell us whether this is version mismatch, OOM, or a real build bug.

[versed galleon]

frank_macmini@macmini:~$ cd ~/Bureau/openclaw
corepack enable
corepack prepare pnpm@10.33.0 --activate

node --version
pnpm --version
free -h
/usr/bin/time -v env OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 pnpm build
Internal Error: EACCES: permission denied, symlink '../lib/node_modules/corepack/dist/yarn.js' -> '/usr/bin/yarn'
at async Object.symlink (node:internal/fs/promises:1001:10)
at async EnableCommand.generatePosixLink (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:23218:5)
at async Promise.all (index 2)
at async EnableCommand.execute (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:23199:5)
at async EnableCommand.validateAndExecute (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:20278:22)
at async _Cli.run (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:21215:18)
at async Object.runMain (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:23704:19)
Preparing pnpm@10.33.0 for immediate activation...
v22.22.2
11.1.0
total utilisé libre partagé tamp/cache disponible
Mem: 7,7Gi 1,4Gi 5,8Gi 5,0Mi 898Mi 6,3Gi
Échange: 4,0Gi 566Mi 3,4Gi
-bash: /usr/bin/time: Aucun fichier ou dossier de ce nom
frank_macmini@macmini:~/Bureau/openclaw$

[uncut shell]

Good, Node is fine and 8 GB RAM + 4 GB swap should at least be enough to test. Two concrete issues in that output:

1. corepack enable failed because it tried to write shims into /usr/bin.
2. pnpm --version is still 11.1.0, so the global pnpm is still being used.

For now, bypass the global pnpm completely and run the pinned version through Corepack:

cd ~/Bureau/openclaw

corepack pnpm@10.33.0 --version
corepack pnpm@10.33.0 install
env OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 corepack pnpm@10.33.0 build

If you want normal pnpm to resolve to the pinned version without sudo, install Corepack shims into your user bin:

[uncut shell]

mkdir -p ~/.local/bin
corepack enable --install-directory ~/.local/bin
export PATH="$HOME/.local/bin:$PATH"
hash -r
pnpm --version

The missing /usr/bin/time is just the time package not being installed. Not important yet. If the build still eats RAM, run this in another terminal while it builds:

free -h
ps -eo pid,ppid,etime,%cpu,%mem,rss,command --sort=-rss | head -20

Paste the output if it stalls or gets killed.

[versed galleon]

I'm trying to understand why I always have problems every time I try to update.

[uncut shell]

The short version: you’re updating from a source checkout, so every update is also a local developer build. That path is powerful, but it is much more sensitive to machine/toolchain details than a packaged install.

In your case I see a few likely repeat offenders:

• Package manager mismatch: the repo pins pnpm@10.33.0, but your shell is running pnpm 11.1.0.
• Corepack shim problem: corepack enable can’t write to /usr/bin, so it prepares pnpm 10 but your normal pnpm command still resolves to global pnpm 11.
• Heavy build step: tsdown can use all cores and a lot of RAM. On an 8 GB Mac mini running Linux, that can feel like the machine is locked up during updates.
• Source installs move with main: if you’re updating often, you may hit build/tooling changes before they’re smoothed out for casual users.

The practical fix is to make updates boring by pinning the toolchain path:

cd ~/Bureau/openclaw
corepack pnpm@10.33.0 install
env OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 corepack pnpm@10.33.0 build

[uncut shell]

And for future updates, prefer this pattern:

cd ~/Bureau/openclaw
git pull
corepack pnpm@10.33.0 install
corepack pnpm@10.33.0 build

If your goal is mainly to use OpenClaw, not hack on the code, source checkout is honestly the bumpiest route. The docs’ “fastest way to get unstuck” advice is here: https://docs.openclaw.ai/help/faq#i-am-stuck-fastest-way-to-get-unstuck

For this specific thread, I’d first fix the pnpm mismatch. Right now the build is happening under a different pnpm than the repo asks for, so we should remove that variable before blaming OpenClaw itself.

[versed galleon]

Just to be sure which exact command I should use to avoid problems with each update?

[uncut shell]

Use this exact update sequence for your source checkout:

cd ~/Bureau/openclaw

git pull --ff-only
corepack pnpm@10.33.0 install --frozen-lockfile
env OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 corepack pnpm@10.33.0 build

openclaw --version

If you run OpenClaw as a gateway service, restart it after the build:

openclaw gateway restart

[uncut shell]

openclaw status

Important bit: for now, do not use plain pnpm install / pnpm build on that machine, because plain pnpm is resolving to 11.1.0. The repo wants 10.33.0, so use corepack pnpm@10.33.0 ... every time until your PATH/Corepack shim is fixed.

[versed galleon]

ℹ target: node22.16.0
ℹ tsconfig: tsconfig.json
ℹ Build start
[tsdown-build] still running pid=2296933; no output for 57s
[tsdown-build] still running pid=2296933; no output for 30s
[tsdown-build] still running pid=2296933; no output for 30s

[uncut shell]

That is still within “probably compiling” territory. You only need to worry if it keeps going for several more minutes and RAM/swap are climbing hard.

Please leave that build running, and in a second terminal run:

free -h
ps -p 2296933 -o pid,etime,%cpu,%mem,rss,vsz,command
ps -eo pid,ppid,etime,%cpu,%mem,rss,command --sort=-rss | head -20

If %CPU is high, it’s working. If %CPU drops near 0 while swap usage rises, it’s memory thrashing.

Also, target: node22.16.0 is the build target, not necessarily your installed Node version, so that line is okay.

[versed galleon]

frank_macmini@macmini:~$ free -h
ps -p 2296933 -o pid,etime,%cpu,%mem,rss,vsz,command
ps -eo pid,ppid,etime,%cpu,%mem,rss,command --sort=-rss | head -20
total utilisé libre partagé tamp/cache disponible
Mem: 7,7Gi 3,3Gi 1,5Gi 5,5Mi 3,2Gi 4,4Gi
Échange: 4,0Gi 398Mi 3,6Gi
PID ELAPSED %CPU %MEM RSS VSZ COMMAND
2296933 02:57 0.6 1.2 101112 1353968 /usr/bin/node /home/frank_macmin
PID PPID ELAPSED %CPU %MEM RSS COMMAND
2296971 2296933 02:57 34.8 24.6 2003152 node ./node_modules/.bin/tsdown --config-loader unrun --logLevel info --no-clean
2297946 2287147 01:19 34.9 3.0 250340 openclaw-update
1319 1268 6-15:11:49 4.1 2.2 181852 /usr/sbin/lightdm-gtk-greeter
2287147 2287122 18:58 3.6 1.9 154596 openclaw-update
2298785 2297946 00:03 33.0 1.6 132776 npm install
2296933 2296901 02:58 0.6 1.2 101112 /usr/bin/node /home/frank_macmini/.cache/node/corepack/v1/pnpm/10.33.0/bin/pnpm.cjs exec tsdown --config-loader unrun --logLevel info --no-clean
2296757 2293018 03:08 0.5 1.2 99824 node /usr/bin/corepack pnpm@10.33.0 build
2296901 2296770 03:00 0.3 0.7 57240 /usr/bin/node scripts/tsdown-build.mjs
2296770 2296769 03:08 0.0 0.5 47872 node scripts/build-all.mjs
1360 1344 6-15:11:44 0.0 0.5 46080 next-server (v16.1.6)
2298252 1 00:49 2.1 0.5 45412 /usr/libexec/fwupd/fwupd
905 1 6-15:12:34 0.0 0.4 37192 npm run start -H 0.0.0.0 -p 3000
2287122 1002 18:59 0.0 0.4 33056 openclaw
1204 1 6-15:12:00 0.0 0.4 32728 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
1018 1000 6-15:12:24 2.0 0.2 23448 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
328 1 6-15:12:58 0.0 0.2 23368 /usr/lib/systemd/systemd-journald
1130 1002 6-15:12:09 0.0 0.2 18364

[uncut shell]

This output is useful: the build is not out of RAM right now. tsdown is using about 2 GB RSS and you still have 4.4 GB available.

The bigger problem is that you appear to have two update/build paths running at the same time:

• manual build: corepack pnpm@10.33.0 build
• background updater: openclaw-update
• plus npm install under that updater

That can absolutely make every update feel cursed.

For this run, I’d avoid changing anything while tsdown is active. Let the current build finish if it’s still progressing. After it finishes, check whether that updater is still running:

pgrep -af 'openclaw-update|npm install|tsdown|build-all'

For future updates, use one path only:

[uncut shell]

• either the built-in updater / app updater
• or the manual source checkout commands

Do not run manual git pull + build while openclaw-update is running. If you want to do manual source updates, stop the gateway/updater first, then update:

openclaw gateway stop
cd ~/Bureau/openclaw
git pull --ff-only
corepack pnpm@10.33.0 install --frozen-lockfile
env OPENCLAW_BUILD_VERBOSE=1 OPENCLAW_TSDOWN_TIMEOUT_MS=600000 corepack pnpm@10.33.0 build
openclaw gateway restart
openclaw status

That background openclaw-update process is probably the missing piece here. Two installers/builders touching the same checkout at once is a recipe for weirdness.

[versed galleon]

i do your command here but i have the same issue ndler.ts, src/hooks/bundled/session-memory/handler.ts
ℹ target: node22.16.0
ℹ tsconfig: tsconfig.json
ℹ Build start
[tsdown-build] still running pid=2302576; no output for 56s
[tsdown-build] still running pid=2302576; no output for 30s
[tsdown-build] still running pid=2302576; no output for 30s

[uncut shell]

That output by itself is still not a failure. It’s the same heartbeat: tsdown has not printed anything for 30s, but it may still be compiling.

The command we used has a 10 minute timeout:

OPENCLAW_TSDOWN_TIMEOUT_MS=600000

So please let it run until either:

• it finishes and moves to the next [build-all] step, or
• it prints [tsdown-build] timeout after 600000ms, or
• Linux kills it with an OOM / “Killed” message.

While it is running, check the real child process again: