[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:

  1. Without socat: the sandboxing feature is silently skipped — no warning, no indication that commands are running unsandboxed.
  2. 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 apt upgrade 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 bwrap sandboxing cannot be applied, Claude Code should warn the user rather than silently skipping or hard-failing.
  • Graceful fallback: if bwrap fails due to missing capabilities, fall back to unsandboxed mode with a visible warning.

Environment

  • Platform: Ubuntu 25.10 (reporter), Ubuntu 24.04 (colleague)
  • Trigger: socat installed via automatic Ubuntu package updates

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗