claude-code - 💡(How to fix) Fix [BUG] Sandbox fails with "bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted" on Ubuntu 25.10 / kernel 6.17 (still broken, ref #14719) [2 comments, 2 participants]

Preflight Checklist

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

What's Wrong?

The sandbox fails immediately on any command with bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted. Claude Code detects the failure, reports "environment lacks user namespace support", and silently auto-disables the sandbox. excludedCommands has no effect since bwrap fails before any command runs.

This is a regression/continuation of #14719, which was closed as not planned but is still reproducible on newer Ubuntu releases and kernels.

What Should Happen?

Sandboxed commands should run without error, or Claude Code should emit a clear, actionable diagnostic explaining the root cause (AppArmor unprivileged_userns restriction) and suggest a fix rather than silently disabling the sandbox.

Error Messages/Logs

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted


Claude Code session output:

● Sandbox init still fails — environment lacks user namespace support.
  excludedCommands can't help if sandbox can't start.

Steps to Reproduce

1. Fresh Ubuntu 25.10 install (kernel 6.17.0-22-generic)
2. Install bubblewrap and socat: sudo apt install bubblewrap socat
3. Set "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true } in ~/.claude/settings.json
4. Launch Claude Code and run any bash command
5. Observe error

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.126 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Diagnosis

Manual bwrap invocation works fine on this system:

$ bwrap --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp bash -c "echo ok"
ok
$ ls -la /usr/bin/bwrap
-rwxr-xr-x 1 root root 84520 Dec 30 2024 /usr/bin/bwrap  # not setuid

User namespaces are enabled:

$ cat /proc/sys/kernel/unprivileged_userns_clone
1

But unprivileged network namespaces are blocked by AppArmor:

$ unshare --net ip link
unshare: unshare failed: Operation not permitted

$ sudo unshare --net ip link  # works only with sudo
1: lo: <LOOPBACK> ...

The sysctl kernel.unprivileged_netns_clone does not exist on this kernel — Ubuntu 25.10 controls this entirely via AppArmor (apparmor_restrict_unprivileged_userns), not via sysctl.

The AppArmor profile at /etc/apparmor.d/bwrap explicitly allows userns for /usr/bin/bwrap, but this is insufficient: the profile permits user namespace creation, yet the network namespace setup inside the sandbox still fails with RTM_NEWADDR: Operation not permitted when Claude Code attempts to configure the loopback interface.

Root Cause

Claude Code's bwrap invocation creates a network namespace and attempts to bring up a loopback interface (RTM_NEWADDR), which requires CAP_NET_ADMIN inside the namespace. On Ubuntu 24.04+ with kernel.apparmor_restrict_unprivileged_userns = 1, this capability is not granted in unprivileged user namespaces.

Environment

• OS: Ubuntu 25.10
• Kernel: 6.17.0-22-generic
• Claude Code: 2.1.126
• bwrap: 0.11.0 (/usr/bin/bwrap, not setuid)
• socat: installed
• kernel.unprivileged_userns_clone = 1
• kernel.unprivileged_netns_clone: sysctl does not exist on this kernel
• AppArmor bwrap profile: present at /etc/apparmor.d/bwrap with allow userns

Suggested Fixes

1. Use --share-net for commands that don't require network isolation — avoids creating a network namespace entirely and sidesteps the RTM_NEWADDR failure.
2. Better diagnostic — detect this failure mode and emit an actionable message (e.g., "AppArmor is blocking unprivileged network namespaces. Run sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 to fix, or disable sandbox.") instead of silently falling back.
3. enableWeakerNestedSandbox as a documented fallback for this class of environment.

Workaround

Disable sandbox and compensate with permissions rules:

{
  "sandbox": { "enabled": false },
  "permissions": {
    "allow": ["Bash(git *)", "Bash(gh *)", "Bash(./gradlew *)"],
    "deny": ["Read(**/.env)", "Read(~/.ssh/*)", "Read(~/.aws/*)"
  }
}

This works but loses OS-level isolation.

Related

• #14719 (same error, Ubuntu 24.04 / kernel 6.8, closed as not planned, now locked)