[Bug] socat presence causes bwrap sandbox to fail silently or error on Ubuntu
Resolved 💬 3 comments Opened Apr 16, 2026 by mbeijen Closed Apr 16, 2026
Bug Description
Claude Code detects socat to enable its bwrap (bubblewrap) sandboxing feature. This creates two problems:
- Without socat: the sandboxing feature is silently skipped — no warning, no indication that commands are running unsandboxed.
- With socat installed: Claude Code wraps shell commands in
bwrap, which then fails on Ubuntu with:
````
apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied
This makes all bash tool calls fail entirely.
Root cause / trigger
Ubuntu automatic updates silently installed socat on affected machines (observed on Ubuntu 24.04 and Ubuntu 25.10), which flipped the sandboxing path and broke Claude Code with no obvious explanation.
Impact
- Commands that worked fine one day break the next after a routine
aptupgrade installs socat as a dependency of something else. - The failure mode is confusing: the error message mentions
bwrap/seccomp, which has no obvious connection to Claude Code's behavior. - Users on kernels/environments that restrict nested user namespaces (common in Ubuntu, containers, CI) cannot use sandboxing even if socat is present.
Expected behavior
- If
bwrapsandboxing cannot be applied, Claude Code should warn the user rather than silently skipping or hard-failing. - Graceful fallback: if
bwrapfails due to missing capabilities, fall back to unsandboxed mode with a visible warning.
Environment
- Platform: Ubuntu 25.10 (reporter), Ubuntu 24.04 (colleague)
- Trigger:
socatinstalled via automatic Ubuntu package updates
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗