Summary

openclaw backup create can produce archives that verify successfully but fail broad extraction on macOS bsdtar because at least one archived hardlink entry has a .. target path.

I hit this during a real restore drill on macOS while testing catastrophic-loss recovery for ~/.openclaw.

What happened

Archive creation + verification both succeeded:

openclaw backup create --output ~/Backups/openclaw --verify
openclaw backup verify ~/Backups/openclaw/<archive>.tar.gz

But broad extraction with the normal documented path failed:

mkdir -p ~/restore-staging
cd ~/restore-staging
tar -xzf ~/Backups/openclaw/<archive>.tar.gz

Observed error:

Path contains '..'

The offending archived entry was under:

workspace-adx/openclaw-src/node_modules/@esbuild/darwin-arm64/bin/esbuild

with a hardlink-like target of:

../workspace-adx/openclaw-src/node_modules/esbuild/bin/esbuild

Why this is a problem

• openclaw backup verify passes, so the archive looks healthy
• but a standard broad restore path can still fail on macOS bsdtar
• this makes backup confidence lower than it appears from verification alone

In my case, selective extraction of key files still worked, but the normal catastrophic-loss “extract the archive” path did not.

Real-world impact

Pre-cleanup drill on macOS:

• archive size: ~2.9G
• entries scanned by openclaw backup verify: 358410
• broad extraction: failed
• selective extraction of key artifacts: succeeded

After removing the offending source/dependency surface from ~/.openclaw, a fresh archive broad-extracted cleanly. So this appears to be a real archive-shape / entry-normalization problem, not operator error.

Repro shape

I realize the exact offending path was specific to my local contents, but the broader bug seems to be:

backup creation can emit tar entries / hardlinks whose link target contains .. in a way that common extraction tools reject.

Expected behavior

One of:

1. backup creation should normalize/avoid such hardlink entries
2. backup creation should de-reference or rewrite them into a restore-safe form
3. openclaw backup verify should detect and flag entries that will fail common extraction paths
4. a dedicated restore command should handle these cases safely

Actual behavior

• archive verifies successfully
• broad extraction can still fail with Path contains '..'

Environment

• OpenClaw: 2026.3.23-2
• OS: macOS arm64
• extractor: system tar / bsdtar

Related

• separate but related: exclude support would reduce the chance of derivative dependency trees causing this in the first place