[BUG] bwrap sandbox broken on merged-usr systems (Arch): "Can't mount tmpfs on /newroot/lib64" — enableWeakerNestedSandbox does not fix it, MCP servers fail to start

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Arch Linux (and any distro using merged-usr where /lib64 is a symlink), the bwrap sandbox fails unconditionally with:

bwrap: Can't mount tmpfs on /newroot/lib64: No such file or directory

This is because /lib64 is a symlink (/lib64 -> usr/lib) and bwrap tries to mount a tmpfs on the symlink target path before resolving it, which fails. Setting enableWeakerNestedSandbox: true does not fix this — the error persists. As a result, MCP servers cannot start at all (they are spawned by Claude Code at startup via the sandbox), and /mcp is unusable.

What Should Happen?

Sandbox starts successfully. Either bwrap uses --symlink usr/lib /lib64 instead of trying to bind-mount /lib64 directly, or enableWeakerNestedSandbox resolves symlinks before constructing the sandbox filesystem.

Error Messages/Logs

bwrap: Can't mount tmpfs on /newroot/lib64: No such file or directory

Steps to Reproduce

Use Arch Linux or any merged-usr distro where /lib64 is a symlink:

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.160

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_