# https://github.com/psyb0t/docker-claudebox 项目说明书

生成时间：2026-07-29 05:39:43 UTC

## 目录

- [项目概览与系统架构](#page-overview)
- [运行模式与接口面](#page-modes)
- [定制化与扩展机制](#page-extension)
- [部署、运维与排障](#page-operations)

<a id='page-overview'></a>

## 项目概览与系统架构

### 相关页面

相关主题：[运行模式与接口面](#page-modes), [部署、运维与排障](#page-operations)

<details>
<summary>相关源码文件</summary>

以下源码文件用于生成本页说明：

- [README.md](https://github.com/psyb0t/docker-claudebox/blob/main/README.md)
- [Dockerfile](https://github.com/psyb0t/docker-claudebox/blob/main/Dockerfile)
- [Dockerfile.full](https://github.com/psyb0t/docker-claudebox/blob/main/Dockerfile.full)
- [CHANGELOG.md](https://github.com/psyb0t/docker-claudebox/blob/main/CHANGELOG.md)
- [claudebox/claudebox/adapter.py](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox/claudebox/adapter.py)
- [claudebox/pyproject.toml](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox/pyproject.toml)
</details>

# 项目概览与系统架构

## 项目定位与核心功能

docker-claudebox 是一个将 Anthropic 的 Claude Code 编程助手封装进 Docker 容器的开源项目，旨在为开发者提供可复现、可移植、隔离的 AI 编程环境。项目通过容器化方案解决了本地直接安装 Claude Code 时遇到的依赖冲突、版本漂移与跨平台兼容性问题。

当前最新发布版本为 **v2.3.6**（参见社区上下文），项目主体由 Python 包 `claudebox`、精简版 `Dockerfile` 与全量版 `Dockerfile.full` 三部分组成。README.md 中将项目定位为"即开即用"的 Claude Code 容器镜像，并强调通过 Docker 把宿主机的 API 凭据与工作目录映射进容器内使用，避免在主机中残留任何全局状态 资料来源：[README.md:1-40]()。

## 系统架构与组件

系统的运行时架构可以划分为四个层级：宿主层、容器层、Python 适配层与 Claude Code 层。Python 包 `claudebox` 中的 `adapter.py` 负责在容器启动时进行 API 凭据注入、模型路由映射以及与 LiteLLM 代理的桥接，使容器内的 Claude Code 能够透明地使用宿主机的配置 资料来源：[claudebox/claudebox/adapter.py:1-80]()。

容器入口通过 `ENTRYPOINT` 与 `CMD` 指令启动适配脚本，再由适配脚本调用 Claude Code CLI。下图展示了从宿主机命令到 Claude Code 调用的数据流：

```mermaid
flowchart TD
    A[宿主机 docker run] --> B[容器 ENTRYPOINT]
    B --> C[claudebox adapter.py]
    C --> D[LiteLLM 代理/直连 API]
    C --> E[Claude Code CLI]
    D --> E
    E --> F[终端输出回传宿主机]
```

适配层的核心职责是**透明转发**：它把宿主机环境变量（如 `ANTHROPIC_API_KEY`、自定义端点）与卷挂载的工作目录透传给 Claude Code，并对模型名称进行规范化处理 资料来源：[claudebox/claudebox/adapter.py:40-120]()。

## 部署形态与镜像变体

项目提供两种构建目标，对应不同的使用场景：

- **精简镜像（`Dockerfile`）**：仅包含运行 Claude Code 必需的运行时与 Python 依赖，镜像体积较小，适合 CI/CD 或一次性任务。
- **全量镜像（`Dockerfile.full`）**：在精简版基础上预装常用开发工具链（`git`、`curl`、`vim`、`build-essential` 等），适合作为日常开发容器 资料来源：[Dockerfile.full:1-60]()。

两个 Dockerfile 都基于官方 Python 或 Debian 基础镜像构建，并通过 `pip install .` 安装本地 `claudebox` 包 资料来源：[Dockerfile:1-50]()。`pyproject.toml` 中声明了项目元数据与依赖，命名空间包结构表明 `claudebox` 是一个可独立发布的 Python 模块 资料来源：[claudebox/pyproject.toml:1-30]()。

## 技术栈与版本演进

项目核心技术栈包括：Python 3.x（适配脚本运行时）、LiteLLM（多模型路由与代理）、Docker（容器化载体）、Anthropic Claude Code CLI（被封装对象）。CHANGELOG.md 记录了从早期版本到 v2.3.6 的迭代轨迹，可见社区关注点集中在**凭据处理安全性**、**镜像体积优化**以及**对 Claude Code 新版本的快速跟进** 资料来源：[CHANGELOG.md:1-80]()。

版本演进体现的几个关键方向：

| 版本阶段 | 主要变化 | 用户关注点 |
|---------|---------|-----------|
| v2.0.x | 引入 LiteLLM 代理集成 | 自定义 API 端点支持 |
| v2.2.x | 重构 adapter.py | 凭据透传稳定性 |
| v2.3.x | 拆分精简与全量镜像 | CI 场景下的体积优化 |
| v2.3.6（当前） | 修复与 Claude Code 版本兼容 | 升级后容器启动失败问题 |

## 使用模式与适用场景

该项目的典型使用模式包括：在 CI 中以精简镜像运行 Claude Code 完成代码审查或自动修复；本地以全量镜像启动交互式开发容器；以及在多模型场景下通过 LiteLLM 路由切换 Claude 之外的模型后端。社区讨论中常见的需求是"如何让容器内的会话保留历史"以及"如何在不暴露 API Key 的前提下共享镜像"，这两点也直接驱动了 adapter 层与构建脚本的持续演进 资料来源：[README.md:40-120]()。

---

<a id='page-modes'></a>

## 运行模式与接口面

### 相关页面

相关主题：[项目概览与系统架构](#page-overview), [定制化与扩展机制](#page-extension), [部署、运维与排障](#page-operations)

>
<summary>相关源码文件</summary>

以下源码文件用于生成本页说明：

- [wrapper.sh](https://github.com/psyb0t/docker-claudebox/blob/main/wrapper.sh)
- [claudebox-entrypoint.sh](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox-entrypoint.sh)
- [claudebox-agent.sh](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox-agent.sh)
- [docs/modes/interactive.md](https://github.com/psyb0t/docker-claudebox/blob/main/docs/modes/interactive.md)
- [docs/modes/programmatic.md](https://github.com/psyb0t/docker-claudebox/blob/main/docs/modes/programmatic.md)
- [docs/modes/api.md](https://github.com/psyb0t/docker-claudebox/blob/main/docs/modes/api.md)
</details>

# 运行模式与接口面

docker-claudebox 通过 `wrapper.sh` 在容器外层统一调度三种运行模式：交互模式（interactive）、程序化模式（programmatic）以及 API 模式（api）。`claudebox-entrypoint.sh` 作为容器入口脚本负责环境初始化与模式分发，`claudebox-agent.sh` 则是实际承载 Claude 代理运行的执行体。三种模式共享同一基础镜像与认证体系，但对外暴露的接口形态与使用契约各不相同。

## 模式分发与容器启动

`wrapper.sh` 解析宿主机传入的命令参数，根据子命令或默认行为决定以何种模式启动容器；随后调用 `docker run` 并将模式相关的环境变量（如 `MODE`、`PORT`、`PROMPT` 等）透传给容器内的 `claudebox-entrypoint.sh`。`claudebox-entrypoint.sh` 在容器启动阶段完成凭证校验、工作目录挂载、依赖检查，最后根据传入的模式分支调用 `claudebox-agent.sh` 的对应执行路径。资料来源：[wrapper.sh:1-80]() 资料来源：[claudebox-entrypoint.sh:10-60]()

## 交互模式（Interactive）

交互模式面向开发者在终端中与 Claude 进行持续对话的场景。`wrapper.sh` 默认以交互模式启动，将宿主 TTY 透传至容器，由 `claudebox-agent.sh` 启动 Claude 的 REPL 界面，支持多轮上下文、文件引用与工具调用。资料来源：[docs/modes/interactive.md:1-40]()

该模式下，`claudebox-agent.sh` 直接以前台进程方式拉起 Claude CLI，保留标准输入输出流，使终端着色、键盘快捷键与历史记录均按原生效。资料来源：[claudebox-agent.sh:20-90]()

## 程序化模式（Programmatic）

程序化模式用于在脚本或自动化流水线中调用 Claude，适合 CI、批处理与一次性问答任务。`wrapper.sh` 在该模式下接收 `--prompt` 或经由标准输入传入的提示词，由 `claudebox-agent.sh` 以非交互方式调用 Claude 并将响应写回标准输出或指定文件，进程结束后立即退出。资料来源：[docs/modes/programmatic.md:1-50]()

此模式不分配 TTY，所有输出以纯文本形式返回，便于 `jq`、重定向或管道后续处理。资料来源：[claudebox-agent.sh:95-140]()

## API 模式（API）

API 模式将 Claude 能力封装为本地 HTTP 服务端口，供同网络下的其他应用调用。`wrapper.sh` 启动容器时暴露容器端口至宿主机，`claudebox-entrypoint.sh` 在该分支下启动 `claudebox-agent.sh` 中内建的 HTTP 服务器，监听 `/v1/chat`、`/health` 等端点，返回与 Anthropic 兼容的 JSON 响应。资料来源：[docs/modes/api.md:1-60]()

API 模式下，凭证仍由容器侧管理，调用方只需关注请求体与认证头，不必在本机安装 Claude CLI。资料来源：[claudebox-agent.sh:150-210]()

## 模式对比与选型

| 模式 | 触发方式 | I/O 形式 | 典型场景 |
|------|---------|---------|---------|
| interactive | 默认启动 / `claudebox` | TTY REPL | 本地探索、调试 |
| programmatic | `--prompt` / 管道 | 标准输出 | 脚本、批处理 |
| api | `claudebox api` | HTTP/JSON | 服务集成、远程调用 |

实际使用时，可根据"是否需要人工对话""是否需要程序化消费""是否需要远程复用"三个维度选择对应模式；同一镜像可随时切换模式而无需重建。资料来源：[wrapper.sh:30-70]()

---

<a id='page-extension'></a>

## 定制化与扩展机制

### 相关页面

相关主题：[运行模式与接口面](#page-modes), [部署、运维与排障](#page-operations)

<details>
<summary>相关源码文件</summary>

以下源码文件用于生成本页说明：

- [docs/customization.md](https://github.com/psyb0t/docker-claudebox/blob/main/docs/customization.md)
- [docs/environment-variables.md](https://github.com/psyb0t/docker-claudebox/blob/main/docs/environment-variables.md)
- [.env.example](https://github.com/psyb0t/docker-claudebox/blob/main/.env.example)
- [claudebox/init.d/10-claude-json-patch.sh](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox/init.d/10-claude-json-patch.sh)
- [claudebox/init.d/20-workspace-claude-md.sh](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox/init.d/20-workspace-claude-md.sh)
- [claudebox/init.d/30-always-skills-seed.sh](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox/init.d/30-always-skills-seed.sh)
</details>

# 定制化与扩展机制

## 概述与设计目标

docker-claudebox 通过"环境变量 + 启动钩子脚本 + 工作区文件"三层结构，提供无需修改镜像即可调整 Claude Code CLI 行为的定制化能力。其核心目标是让用户在保持镜像不可变（immutable）的前提下，按需注入凭据、修改默认配置、扩展项目上下文与技能（skills）。v2.3.6 版本延续并增强了该机制，所有定制入口均集中于 `.env` 文件与 `claudebox/init.d/` 目录中按数字前缀排序执行的脚本 资料来源：[docs/customization.md:1-40]() 资料来源：[claudebox/init.d/10-claude-json-patch.sh:1-15]()。

## 环境变量驱动的配置层

`.env.example` 列出了全部可调参数，作为容器启动时被读取的默认模板。用户只需复制为 `.env` 并按需修改即可生效，主要类别包括：

- **运行时身份**：如 `CLAUDEBOX_USER`、`CLAUDEBOX_UID`，控制容器内执行用户。
- **网络与代理**：`HTTP_PROXY`、`HTTPS_PROXY` 等，决定 Claude CLI 出站流量。
- **Claude 凭据**：`ANTHROPIC_API_KEY`、`CLAUDE_CODE_OAUTH_TOKEN` 等鉴权字段。
- **行为开关**：例如是否启用技能自动播种、是否挂载自定义 init 脚本等。

详细字段说明见官方文档，所有变量在容器入口脚本（entrypoint）启动前完成注入，因此可在 init.d 脚本中被直接读取 资料来源：[.env.example:1-60]() 资料来源：[docs/environment-variables.md:1-80]()。

## init.d 启动钩子系统

`claudebox/init.d/` 目录是扩展机制的运行时主干。容器入口脚本会按文件名前缀的数字顺序（10、20、30…）依次执行所有 `.sh` 文件，从而形成确定性的初始化流水线。当前随仓库发布的三个核心脚本职责清晰、互不耦合：

### 1. Claude JSON 配置修补（10-claude-json-patch.sh）

该脚本在启动早期阶段运行，负责对 `~/.claude.json` 或等价配置文件进行就地补丁，注入或覆盖默认的模型、主题、MCP 服务等设置，保证每次容器启动后 Claude CLI 都获得期望的初始配置 资料来源：[claudebox/init.d/10-claude-json-patch.sh:1-60]()。

### 2. 工作区 CLAUDE.md 注入（20-workspace-claude-md.sh）

该脚本在工作区挂载完成后执行，将宿主机的 `CLAUDE.md`（若存在）拷贝或软链到 Claude CLI 能识别的项目级指令位置，使项目特定的约定、代码风格与背景说明自动进入上下文 资料来源：[claudebox/init.d/20-workspace-claude-md.sh:1-50]()。

### 3. 技能自动播种（30-always-skills-seed.sh）

作为流水线末端步骤，它会把镜像内置或环境变量指定的技能目录复制到用户实际的 `~/.claude/skills/` 下，确保即使用户工作区为空也能使用基础技能集合 资料来源：[claudebox/init.d/30-always-skills-seed.sh:1-55]()。

下图展示了容器启动时各定制层级的执行顺序与依赖关系：

```mermaid
flowchart LR
    A[读取 .env 环境变量] --> B[entrypoint 启动]
    B --> C[10-claude-json-patch.sh]
    C --> D[20-workspace-claude-md.sh]
    D --> E[30-always-skills-seed.sh]
    E --> F[Claude CLI 就绪]
```

## 用户级扩展路径

除镜像内置钩子外，用户可将自己的 `.sh` 文件放入 `claudebox/init.d/` 目录（建议使用大于 30 的数字前缀以避免冲突），从而无侵入地追加定制步骤，例如安装额外工具、预热缓存或注册额外 MCP 服务。结合 `.env` 中提供的开关变量，用户脚本还能实现条件化执行 资料来源：[docs/customization.md:40-90]()。

## 工作区级与技能级扩展

在工作区根目录放置 `CLAUDE.md` 是最高频的轻量定制方式：项目说明、架构文档、操作规约都会在每次会话开始时自动加载 资料来源：[claudebox/init.d/20-workspace-claude-md.sh:10-30]()。技能（skills）层面则通过镜像内置目录与 `30-always-skills-seed.sh` 的播种逻辑结合，用户既可使用仓库自带技能，也可将自己的技能目录挂载到容器内相应路径进行覆盖或追加 资料来源：[claudebox/init.d/30-always-skills-seed.sh:5-40]()。

## 总结

整套定制化与扩展机制遵循"配置外置、行为可插拔、镜像不可变"的十二要素原则：`.env` 控制可变配置，`init.d/*.sh` 提供按序执行的扩展点，`CLAUDE.md` 与技能目录承载项目级语义。用户无需重新构建镜像，即可在不同项目、不同凭据、不同行为模式下复用同一 docker-claudebox 实例，显著降低运维成本 资料来源：[docs/customization.md:90-120]()。

---

<a id='page-operations'></a>

## 部署、运维与排障

### 相关页面

相关主题：[项目概览与系统架构](#page-overview), [运行模式与接口面](#page-modes), [定制化与扩展机制](#page-extension)

<details>
<summary>相关源码文件</summary>

以下源码文件用于生成本页说明：

- [install.sh](https://github.com/psyb0t/docker-claudebox/blob/main/install.sh)
- [wrapper.sh](https://github.com/psyb0t/docker-claudebox/blob/main/wrapper.sh)
- [claudebox-entrypoint.sh](https://github.com/psyb0t/docker-claudebox/blob/main/claudebox-entrypoint.sh)
- [Makefile](https://github.com/psyb0t/docker-claudebox/blob/main/Makefile)
- [test.sh](https://github.com/psyb0t/docker-claudebox/blob/main/test.sh)
- [run-e2e-cron-telegram.sh](https://github.com/psyb0t/docker-claudebox/blob/main/run-e2e-cron-telegram.sh)
</details>

# 部署、运维与排障

本页面向运维与开发人员说明 docker-claudebox 的安装部署、日常运行与常见故障排查方法，覆盖安装脚本、容器封装、构建任务、测试与端到端自动化等关键流程。

## 项目定位与整体结构

docker-claudebox 通过若干 Shell 脚本与 Makefile，将 Claude CLI 运行环境封装为一个可复用的 Docker 镜像，并以 `wrapper` 命令形式对外暴露，使用户在宿主机上即可启动容器化的 Claude 会话。当前发布版本为 **v2.3.6**。

脚本职责分布如下：

| 文件 | 主要职责 |
| --- | --- |
| install.sh | 镜像构建与本地安装入口 |
| wrapper.sh | 宿主机侧的 CLI 包装，调用 docker run |
| claudebox-entrypoint.sh | 容器内部入口脚本，准备运行环境 |
| Makefile | 统一构建、测试、清理任务入口 |
| test.sh | 单元/集成测试脚本 |
| run-e2e-cron-telegram.sh | 通过 cron + Telegram 的端到端测试 |

## 部署流程

### 基于 install.sh 的快速安装

`install.sh` 是官方推荐的部署入口，负责拉取源码、构建镜像并把 `wrapper.sh` 链接或拷贝到系统 PATH，使 `claudebox` 或 `cbx` 命令可在任意目录调用。脚本通常会校验 Docker 可用性、必要目录与权限后再执行构建。

资料来源：[install.sh:1-120]()

### 基于 Makefile 的构建任务

Makefile 将构建、清理、安装、测试等流程抽象为标准 `make` 目标，便于在 CI 或开发机中复用。典型用法包括：

- `make build`：构建本地镜像
- `make install`：调用 install.sh 完成全量部署
- `make clean`：清理悬空镜像与构建缓存
- `make test`：触发 test.sh

资料来源：[Makefile:1-80]()

## 运维与日常使用

### wrapper.sh：宿主与容器的桥梁

`wrapper.sh` 是用户在终端实际调用的脚本，它封装 `docker run` 的所有参数，包括镜像标签、容器名称、环境变量、卷挂载（如 `~/.claude`、SSH 配置、git 凭据）以及交互式 TTY 设置。常见使用模式：

```bash
claudebox                 # 启动默认会话
claudebox --help          # 查看支持的子命令
claudebox update          # 拉取最新镜像并重建容器
```

为保证升级安全，`wrapper.sh` 通常会先检查现有容器是否运行，并在必要时执行 stop/remove。资料来源：[wrapper.sh:1-200]()

### claudebox-entrypoint.sh：容器内部初始化

容器启动后，`claudebox-entrypoint.sh` 在 PID 1 位置接管流程，完成以下工作：

1. 校验必要的环境变量与 API Key；
2. 准备工作目录、git 配置与 SSH 凭据；
3. 调用 `claude` 二进制进入交互模式。

该脚本对启动失败时的退出码与日志输出有明确定义，便于排障时定位问题。资料来源：[claudebox-entrypoint.sh:1-150]()

## 测试与端到端验证

### test.sh：本地自动化测试

`test.sh` 覆盖构建结果、wrapper 行为、镜像存在性等检查，常用于 PR 与本地回归。它会调用 Makefile 中定义的测试目标，并输出简洁的 PASS/FAIL 摘要。

资料来源：[test.sh:1-100]()

### run-e2e-cron-telegram.sh：跨周期验证

该脚本以 cron 方式周期性触发完整链路：调用 wrapper 启动容器 → 执行预设任务 → 通过 Telegram Bot 回传结果，用于验证长时间运行的可靠性。它既可作为冒烟测试，也可作为监控探针。

资料来源：[run-e2e-cron-telegram.sh:1-120]()

## 排障指南

```mermaid
flowchart TD
    A[claudebox 启动失败] --> B{Docker 可用?}
    B -- 否 --> C[安装/启动 Docker 守护进程]
    B -- 是 --> D{镜像存在?}
    D -- 否 --> E[运行 install.sh 或 make build]
    D -- 是 --> F{容器冲突?}
    F -- 是 --> G[wrapper.sh 移除旧容器]
    F -- 否 --> H{entrypoint 报错?}
    H --> I[检查 API Key 与挂载卷]
    H --> J[查看 docker logs 定位]
```

常见故障及处理：

- **镜像未找到**：重新执行 `install.sh` 或 `make build`。
- **容器名称冲突**：`wrapper.sh` 内置同名容器清理逻辑；若是自定义名称，需手动 `docker rm -f`。
- **API Key 无效**：检查 `claudebox-entrypoint.sh` 读取的 `.env` 或环境变量。
- **挂载卷丢失**：确认宿主机路径存在且权限正确，特别是 `~/.claude` 与 SSH 目录。
- **升级后行为异常**：比对 `Makefile` 中版本标签，必要时回滚到 v2.3.6 之前版本。

持续集成与监控可结合 `run-e2e-cron-telegram.sh` 的 Telegram 通知能力，在异常发生时立即收到告警。

## 后续维护建议

- 将 `install.sh` 与 Makefile 目标纳入 CI，确保每次发版都有可重复的部署产物。
- 使用 `test.sh` 作为合并门禁，`run-e2e-cron-telegram.sh` 作为夜间巡检。
- 在升级到 v2.3.6 之后版本时，先在非生产环境跑通端到端脚本，再切换线上实例。

---

<!-- evidence_pipeline_checked: true -->
<!-- evidence_injected: true -->

---

## Doramagic 踩坑日志

项目：psyb0t/docker-claudebox

摘要：发现 9 个潜在踩坑项，其中 0 个为 high/blocking；最高优先级：配置坑 - 可能修改宿主 AI 配置。

## 1. 配置坑 · 可能修改宿主 AI 配置

- 严重度：medium
- 证据强度：source_linked
- 发现：项目面向 Claude/Cursor/Codex/Gemini/OpenCode 等宿主，或安装命令涉及用户配置目录。
- 对用户的影响：安装可能改变本机 AI 工具行为，用户需要知道写入位置和回滚方法。
- 证据：capability.host_targets | https://github.com/psyb0t/docker-claudebox | host_targets=mcp_host, claude_code, claude, chatgpt

## 2. 能力坑 · 能力判断依赖假设

- 严重度：medium
- 证据强度：source_linked
- 发现：README/documentation is current enough for a first validation pass.
- 对用户的影响：假设不成立时，用户拿不到承诺的能力。
- 证据：capability.assumptions | https://github.com/psyb0t/docker-claudebox | README/documentation is current enough for a first validation pass.

## 3. 运行坑 · 运行可能依赖外部服务

- 严重度：medium
- 证据强度：source_linked
- 发现：项目说明出现 external service/cloud/webhook/database 等运行依赖关键词。
- 对用户的影响：本地安装成功不等于能力可用，外部服务不可用会阻断体验。
- 证据：packet_text.keyword_scan | https://github.com/psyb0t/docker-claudebox | matched external service / cloud / webhook / database keyword

## 4. 维护坑 · 维护活跃度未知

- 严重度：medium
- 证据强度：source_linked
- 发现：未记录 last_activity_observed。
- 对用户的影响：新项目、停更项目和活跃项目会被混在一起，推荐信任度下降。
- 证据：evidence.maintainer_signals | https://github.com/psyb0t/docker-claudebox | last_activity_observed missing

- 严重度：medium
- 证据强度：source_linked
- 发现：no_demo
- 证据：downstream_validation.risk_items | https://github.com/psyb0t/docker-claudebox | no_demo; severity=medium

## 6. 安全/权限坑 · 存在安全注意事项

- 严重度：medium
- 证据强度：source_linked
- 发现：No sandbox install has been executed yet; downstream must verify before user use.
- 对用户的影响：用户安装前需要知道权限边界和敏感操作。
- 证据：risks.safety_notes | https://github.com/psyb0t/docker-claudebox | No sandbox install has been executed yet; downstream must verify before user use.

## 7. 安全/权限坑 · 存在评分风险

- 严重度：medium
- 证据强度：source_linked
- 发现：no_demo
- 对用户的影响：风险会影响是否适合普通用户安装。
- 证据：risks.scoring_risks | https://github.com/psyb0t/docker-claudebox | no_demo; severity=medium

## 8. 维护坑 · issue/PR 响应质量未知

- 严重度：low
- 证据强度：source_linked
- 发现：issue_or_pr_quality=unknown。
- 对用户的影响：用户无法判断遇到问题后是否有人维护。
- 证据：evidence.maintainer_signals | https://github.com/psyb0t/docker-claudebox | issue_or_pr_quality=unknown

## 9. 维护坑 · 发布节奏不明确

- 严重度：low
- 证据强度：source_linked
- 发现：release_recency=unknown。
- 对用户的影响：安装命令和文档可能落后于代码，用户踩坑概率升高。
- 证据：evidence.maintainer_signals | https://github.com/psyb0t/docker-claudebox | release_recency=unknown

<!-- canonical_name: psyb0t/docker-claudebox; human_manual_source: deepwiki_human_wiki -->