Pre-checks

• I have searched existing issues and this is not a duplicate.

Deployment Method

Docker

Steps to Reproduce

宿主机：Ubuntu 24.04+（本例内核 7.0.0-38-generic），保持默认 kernel.apparmor_restrict_unprivileged_userns=1
按官方 README 部署：git clone ... && cd Clawith && cp .env.example .env && docker compose up -d（镜像构建包含 backend/Dockerfile 中对 /usr/bin/bwrap 的 chmod u+s）
在 UI 中让任意 Agent 使用内置 execute_code 工具执行任意代码（如 print("hello")）
观察工具结果；重复执行
实测数据：数据库 agent_tool_executions 中 execute_code 共 64 次调用，failed 64 / success 0，错误均为 sandbox_persistent_execution_failed: RuntimeError。

Expected vs Actual Behavior

Expected：代码在 bubblewrap 沙箱内执行，返回脚本 stdout（如 hello）；环境不支持时返回明确、可操作的错误信息。

Actual：每次调用必然失败，仅返回异常类名 RuntimeError，无任何细节、无后端日志，无法定位。

根因分析
Ubuntu 24.04+ 默认禁止非特权进程创建 user namespace（宿主机实测 unshare -Ur → Operation not permitted）
backend/Dockerfile 的 chmod u+s /usr/bin/bwrap 是针对该限制的旧式兼容手段
当前 bubblewrap 版本拒绝 setuid 运行：容器内以 backend 运行用户 clawith 执行 bwrap 报 bwrap: setuid use of bubblewrap is not supported；去掉 setuid 后又因内核限制报 setting up uid map: Permission denied —— 两条路均不可用
backend 进程以非 root 的 clawith 运行 → 持久 bwrap 会话启动即退出 → subprocess_backend.py:1013 抛 RuntimeError
subprocess_backend.py:1216-1224 的兜底 catch 仅保留 type(exc).name、丢弃消息且不写日志，导致错误不可诊断（docker exec 默认以 root 探测会全部通过，极易误导排查）

Logs / Screenshots

临时解决（已验证有效）

宿主机

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
echo 'kernel.apparmor_restrict_unprivileged_userns=0' | sudo tee /etc/sysctl.d/99-userns-compat.conf

运行中的 backend 容器

sudo docker exec -u root clawith-backend-1 chmod u-s /usr/bin/bwrap

之后 execute_code 端到端恢复正常（无需重启 backend）。

建议修复
backend/Dockerfile 移除 chmod u+s /usr/bin/bwrap（新版 bubblewrap 一律拒绝 setuid，该行在所有新镜像上均为有害），并在注释中说明内核 userns 要求
subprocess_backend.py 三处 catch（persistent 1216、publication 1166/1358）保留有界异常详情（str(exc)[:500]）并补 logger.exception
可选：backend 启动时以运行用户预检 bwrap 能力，把环境误配置提前到最早失败点
环境：Docker Compose 部署；backend 镜像基于 python:3.12-slim（Debian trixie，bubblewrap 拒绝 setuid）；backend 容器 privileged + seccomp=unconfined（仓库默认配置，非权限缺失问题）。