Codexbox

io.github.psyb0t由 GitHub 帳號 psyb0t 發布v0.7.6更新於 Oct 29, 2026

Self-hosted MCP server: run OpenAI Codex CLI prompts and manage workspace files.

概覽

AI 產生的概覽

自架設的 Docker 容器,執行 OpenAI Codex CLI 提示,並透過 MCP 向其他代理提供執行提示與工作區檔案工具。

可以做什麼
  • 執行 Codex 提示:提供 run_prompt,讓其他代理把 Codex CLI 當成工具呼叫
  • 管理工作區檔案:在限定工作區內列出、上傳、下載與刪除檔案,並檢查路徑穿越
  • 控制執行:選擇模型、推理強度、系統提示,續接工作階段或開啟全新工作階段
  • 透過 streamable HTTP 提供:API 模式下掛載於 API 連接埠的 /mcp/,其他模式下以獨立連接埠的 sidecar 執行
  • 與其他模式並存:API、Telegram 機器人與 cron 排程器可同時運作
適用情境
適合想要自架設、容器化的 Codex 代理,並讓其他 MCP 用戶端或代理把它當成工具呼叫,且需要獨立工作區與持久登入的情況。適合已在用 Docker、希望依目錄隔離 Codex 工作而非直接在主機上執行的人。
執行需求
主機需安裝並執行 Docker;服務以本機容器映像方式執行。需要 Codex 驗證:OPENAI_API_KEY(可搭配 OPENAI_BASE_URL),或一次性 ChatGPT 訂閱 OAuth 登入並持久化到綁定的 ~/.codex 目錄。以 CODEXBOX_MCP_MODE=1 啟用 MCP 模式,可用 CODEXBOX_MCP_MODE_TOKEN 保護。需要連線至 OpenAI 的網路。
安裝前請注意
容器內部會注入繞過沙箱的旗標,提示可執行 shell 指令並修改掛載的工作區。OPENAI_API_KEY 與 OAuth 權杖存放在掛載的 ~/.codex 目錄,CODEXBOX_ENV_* 會把任意主機環境變數轉送進容器。選用掛載 SSH agent 後,其中所有金鑰在容器內皆可使用。完整映像捆綁了 BUSL-1.1 授權的 Terraform,並非 OSI 開源。安裝腳本為遠端 shell 腳本。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Codexbox,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

docker-codexbox

[CI] [version] [license] [Docker Pulls]

OpenAI Codex CLI inside an aicodebox container. Minimal and toolchain-loaded images, five ways in: interactive shell, one-shot exec, OpenAI-compatible endpoint, MCP server, Telegram bot, and a cron scheduler that fires codex on whatever schedule you want.

You talk to codexbox. codexbox talks to codex. codex talks to OpenAI — or your ChatGPT subscription. Nobody cares about the middle.

Table of Contents

Quick start

Docker installed and running is the only prerequisite.

One-liner install

The installer pulls the selected image, creates the persistent Codex and SSH directories, downloads the wrapper, and installs codexbox on your PATH.

bash
# minimal image — defaultcurl -fsSL https://raw.githubusercontent.com/psyb0t/docker-codexbox/master/install.sh | bash
# full image — every development tool pre-installedexport CODEXBOX_FULL=1 && curl -fsSL https://raw.githubusercontent.com/psyb0t/docker-codexbox/master/install.sh | bash
# custom command namecurl -fsSL https://raw.githubusercontent.com/psyb0t/docker-codexbox/master/install.sh | bash -s -- codex

Installing with CODEXBOX_FULL=1 bakes latest-full into the wrapper, so the choice persists; you do not need to export it again. CODEXBOX_FULL must be set for bash, not merely for curl, hence the export … && form above.

Local checkout

From a checkout of this repository, build the matching image and install the local wrapper without pulling a published codexbox image:

bash
make install       # minimal imagemake install-full  # full image
# install only the local wrapper; do not build or pullmake install-wrapperCODEXBOX_FULL=1 make install-wrapper  # full image

These targets set CODEXBOX_SRC_LOCAL=true. make install and make install-full build their image first; make install-wrapper only installs the local wrapper.sh against the selected existing image. It fails if that image is absent instead of falling back to docker pull.

The remote installer downloads wrapper.sh from its matching release tag. Automation can set CODEXBOX_INSTALL_DIR, CODEXBOX_BIN_NAME, and AICODEBOX_MANAGED_INSTALL=1 when it installs into a different command directory without prompting to replace an existing SSH key.

Using the codexbox wrapper

The wrapper mounts the current directory as the workspace, persists ~/.codex (so login survives container recreation), forwards auth and configured environment variables, and manages a per-directory container.

bash
export OPENAI_API_KEY=sk-...         # or use a subscription: `codexbox login --device-auth`
codexbox                             # interactive TUI — continues the last session for THIS dircodexbox --no-continue               # same, but starts a brand-new session insteadcodexbox exec "fix the failing test in ./app"   # one-shot codex exec, output to your terminalecho "summarize README.md" | codexbox exec -     # prompt via stdincodexbox login --device-auth         # ChatGPT-subscription OAuth login (persists in ~/.codex)codexbox login status                # which auth mode is activecodexbox --version                   # passthrough to `codex --version`codexbox stop                        # stop this dir's running container(s)codexbox clear-session               # drop codex's saved sessions (keeps auth + config)

The wrapper forwards "$@" straight to the image, so any codex subcommand works (codexbox mcp ..., codexbox doctor, etc.). The sandbox-bypass flag is injected inside the container — you never pass it yourself.

The bare interactive TUI defaults to continuing the most recent session for the directory you're in (same idea as claudebox's default) — codex's own resume --last cwd-scopes the lookup and starts a fresh session automatically when there's nothing to resume, so this is safe on a brand-new workspace too. Pass --no-continue to force a fresh session instead.

Install codexbox, claudebox, and pibox in the same command directory, normally /usr/local/bin, when one box needs to launch another. The wrapper finds sibling wrapper files there and mounts them read-only into the container. A sibling wrapper then runs through the host Docker daemon and mounts its own host data directory. Codexbox does not directly mount another agent's home.

Agent use and nested launches

The installed wrapper is the normal interface for people and agents. An agent should run codexbox from the requested workspace instead of assembling a new docker run command. The wrapper preserves the workspace path, Codex state, SSH state, image choice, and per-workspace container lifecycle.

bash
codexbox exec "inspect this workspace and report the failing tests"CODEXBOX_FULL=1 codexbox exec "run the full test suite"printf '%s\n' "summarize README.md" | codexbox exec -

When one box needs another, install codexbox, claudebox, and pibox in the same command directory. A running box can call the sibling command directly. The parent wrapper passes the host launch context and mounts only the sibling wrapper file. Do not set AICODEBOX_HOST_*, copy a wrapper, or manually mount another box's state directory.

The wrapper does not forward an SSH agent on its own. To give the box your agent, mount its socket and point SSH_AUTH_SOCK at it:

bash
CODEXBOX_MOUNT_SSH="$SSH_AUTH_SOCK:/ssh-agent:ro" CODEXBOX_ENV_SSH_AUTH_SOCK=/ssh-agent codexbox

Every key loaded in that agent becomes usable inside the box.

Manual Docker use

Use raw Docker only for an explicitly requested container deployment. The wrapper is the normal route for interactive, one-shot, and local service use. The Modes section has the relevant deployment commands and configuration.

Image variants

  • psyb0t/codexbox:latest is the default minimal image: Codex, Node.js, Python, uv, Docker, Git, jq, and curl.
  • psyb0t/codexbox:latest-full starts from the shared aicodebox:latest-full base, then adds Codexbox's adapter, entrypoint, auth, and config.

CODEXBOX_FULL is binary: the installer defaults to minimal, 0 selects minimal, and 1 selects full. At runtime, an unset value preserves the installed image choice. Any other value fails. The installer writes the resolved image into the installed wrapper, so the choice persists without exporting the variable on every run. A runtime CODEXBOX_FULL=0 or CODEXBOX_FULL=1 temporarily forces a variant; CODEXBOX_IMAGE remains the highest-priority explicit override.

The full image adds:

  • Go 1.27.2 with gopls, Delve, golangci-lint, staticcheck, gofumpt, and test/code-generation helpers
  • Python 3.14.8 with pytest, Black, Flake8, mypy, Pyright, Poetry, Pipenv, and common HTTP/parsing libraries
  • JavaScript and TypeScript linting, formatting, process, framework, API-test, static-server, Lighthouse, and Storybook CLIs
  • GitHub CLI, Terraform, kubectl, and Helm
  • Build tools, CMake, ClangFormat, Valgrind, GDB, strace, and ltrace
  • PostgreSQL, MySQL, SQLite, and Redis clients
  • Vim, Nano, tmux, htop, archive tools, network diagnostics, ripgrep, fd, bat, eza, shellcheck, and shfmt

The full variant inherits the shared Aicodebox full image. Aicodebox owns the shared toolchain pins, locks, and supply-chain checks. Codexbox adds only its agent package and startup layer.

Licensing note: the minimal image is clean — just Apache-2.0 Codex on top of the aicodebox base. The full image additionally bundles HashiCorp Terraform, which is BUSL-1.1 (source-available, non-compete), not OSI-approved open source. If that matters to your use case, stick to the minimal image or review the BUSL-1.1 terms yourself before using latest-full. Full breakdown in THIRD_PARTY.md.

Wrapper environment variables

Set CODEXBOX_GIT_NAME and CODEXBOX_GIT_EMAIL on the host to configure the runtime user's global Git identity before startup hooks. Direct container deployments accept the same names. Nonempty AICODEBOX_GIT_NAME and AICODEBOX_GIT_EMAIL inside the container take precedence; through the wrapper, supply those shared values as AICODEBOX_ENV_AICODEBOX_GIT_NAME and AICODEBOX_ENV_AICODEBOX_GIT_EMAIL. Empty settings preserve existing Git config. Multiline values are rejected.

make version V=X.Y.Z synchronizes package metadata, lockfile, the Codex plugin manifest, and the installer's wrapper release ref without committing or tagging. Remote installs download the matching release wrapper unless CODEXBOX_INSTALL_REF overrides it. Updating an image does not update an installed wrapper.

Set these on the host before running codexbox:

VarDefaultWhat it does
OPENAI_API_KEY—API-key auth (seeded into ~/.codex/auth.json on boot). Not needed for subscription login.
OPENAI_BASE_URL—Point codex at an OpenAI-compatible endpoint
CODEXBOX_IMAGEinstalled imageOverride the image the wrapper runs
CODEXBOX_FULLinstalled choice (0 initially)0 forces minimal; 1 forces full
CODEXBOX_DATA_DIR~/.codexHost dir mounted as CODEX_HOME (auth + config + sessions)
CODEXBOX_SSH_DIR~/.ssh/codexboxSSH key directory mounted into the container (for git over SSH)
CODEXBOX_MAX_MEM10gPer-container memory limit
CODEXBOX_CONTAINER_NAMEderived from $PWDOverride the per-workspace container name
CODEXBOX_ENV_*—Forward arbitrary env into the container (prefix stripped: CODEXBOX_ENV_FOO=bar → FOO=bar)
CODEXBOX_MOUNT_*—Mount extra host dirs (/host:/container syntax, or a bare path for same-path-both-sides)
AICODEBOX_ENV_*—Forward a shared environment variable into the launched container, with the prefix stripped
AICODEBOX_MOUNT_*—Mount a shared host directory into the launched container

AICODEBOX_HOST_* is the versioned nested-launch context used by sibling wrappers. It records host bind-source paths and is set automatically by a wrapper. Do not set it for an ordinary host launch.

CODEXBOX_MODE_CRON=1 + CODEXBOX_MODE_CRON_FILE=/path/cron.yaml codexbox starts the cron scheduler as a long-running background container instead.

Prefer no host install? Everything the wrapper does is plain docker run; see Manual Docker use and Modes.

Modes

Foreground modes (API / Telegram / Cron) are mutually exclusive — except CODEXBOX_TELEGRAM_MODE=1 + CODEXBOX_CRON_MODE=1, which run together (cron in-thread inside telegram). API wins if set alongside anything else.

MCP mode (CODEXBOX_MCP_MODE=1) is independent — it coexists with whatever foreground mode is running. In API mode it's mounted at /mcp/ on the API port; in other modes it runs as a sidecar uvicorn on its own port.

Each mode has its own page with full setup, env vars, and examples.

API Mode →

Long-lived FastAPI server on :8080. Agent runs (sync, async with run-id polling, cancellable), workspace file upload/download/list/delete with traversal checking, and an OpenAI-compatible chat/completions endpoint with streaming and client-executed tool calling. Codex's native --output-schema backs jsonSchema, so schema-conforming output needs no retries.

yaml
environment:  - CODEXBOX_API_MODE=1  - CODEXBOX_API_MODE_TOKEN=your-secret  - CODEXBOX_AVAILABLE_MODELS=gpt-5.1-codex,gpt-5.1-codex-mini

Telegram Mode →

Talk to codex from Telegram. Per-chat isolated workspaces, allowed-chats and per-chat allowed-users gating, file ingestion, [SEND_FILE: path] to get files back, and per-chat /model, /effort, /system_prompt, /append_system_prompt overrides that persist across restarts.

yaml
environment:  - CODEXBOX_TELEGRAM_MODE=1  - CODEXBOX_TELEGRAM_MODE_TOKEN=123456:ABC

Cron Mode →

YAML-defined scheduled jobs on 6-field croniter schedules. Per-run history dirs with meta.json, stdout.log, stderr.log, result.txt, and a "prior run" hint so a job can reference its own history.

yaml
environment:  - CODEXBOX_CRON_MODE=1  - CODEXBOX_CRON_MODE_FILE=/home/aicode/.aicodebox/cron.yaml

MCP Mode →

Exposes run_prompt plus workspace-confined file tools over streamable HTTP, so other agents can drive codex as a tool. Coexists with any foreground mode — mounted at /mcp/ on the API port in API mode, served at its own port root everywhere else. Distinct from codex's own MCP client/server support, which codexbox does not wire up.

yaml
environment:  - CODEXBOX_MCP_MODE=1  - CODEXBOX_MCP_MODE_TOKEN=your-secret

Configuration

Naming convention: CODEXBOX_<MODE>_MODE=1 is the on/off flag, CODEXBOX_<MODE>_MODE_<KNOB>=... is its config. Non-mode-scoped vars (workspace, container name, available models) are bare.

The image is built on top of aicodebox, so the equivalent AICODEBOX_* names also work — the entrypoint translates CODEXBOX_X to AICODEBOX_X when only the codexbox-prefixed one is set. If you set both, AICODEBOX_* wins.

Mode flags

VarDefaultWhat it does
CODEXBOX_API_MODE0Boot the HTTP API server (foreground)
CODEXBOX_TELEGRAM_MODE0Boot the Telegram bot (foreground)
CODEXBOX_CRON_MODE0Boot the cron scheduler (foreground; in-thread when telegram is also on)
CODEXBOX_MCP_MODE0Expose MCP — mounted at /mcp/ in API mode, or as a sidecar elsewhere

Each mode's own knobs (ports, tokens, config paths, history dirs) live on that mode's page: api.md, telegram.md, cron.md, mcp.md.

Workspace & runtime

VarDefaultWhat it does
CODEXBOX_WORKSPACE/workspaceRoot workspace dir inside the container
CODEXBOX_CONTAINER_NAMEaicodeboxUsed to scope per-container state files (auth, etc.)
CODEXBOX_AVAILABLE_MODELS—Required for API mode. CSV list returned by /openai/v1/models and shown in the telegram /model picker. API mode refuses to boot without it; telegram /model picker degrades to a "set this env var" reply.
CODEXBOX_AVAILABLE_EFFORTSnone,minimal,low,medium,high,xhigh,maxOverride the effort/reasoning list shown by the telegram /effort picker (comma-separated)
CODEXBOX_MODEL—Default model passed to codex (-m/--model) when a caller doesn't specify one

Init scripts and user bin

$HOME/.aicodebox/bin is on PATH ahead of everything else, for codex itself, for init scripts, and for docker exec shells. Drop your own scripts there.

$HOME/.aicodebox/init.d/*.sh run once per container, after the image's own /aicodebox-init.d/*.sh, as aicode with passwordless sudo. A failing script is logged and the rest still run. Bind-mount $HOME/.aicodebox to supply either directory. A fresh container runs init again even against a previously used $HOME/.aicodebox, so your scripts need to be safe to repeat.

Auth

codex supports two distinct auth modes. Pick one.

1. API key (pay-as-you-go)

Set OPENAI_API_KEY. Optionally OPENAI_BASE_URL to point at an OpenAI-compatible endpoint instead of the default OpenAI API.

bash
docker run --rm \  -e OPENAI_API_KEY=sk-... \  -v "$PWD/.codex:/home/aicode/.codex" \  psyb0t/codexbox:latest \  exec "say HELLO"

The container seeds codex's $CODEX_HOME/auth.json from OPENAI_API_KEY on boot (codex login --with-api-key under the hood, reading the key from stdin — codex does not accept a bare OPENAI_API_KEY env var for codex exec; it needs the login step to actually write auth.json). This seeding is safe to run on every boot: it only writes apikey-mode auth, and never touches an existing ChatGPT-subscription login (see below).

2. ChatGPT subscription (Plus / Pro / Team)

No API key at all — codex bills against your ChatGPT subscription instead. This requires a one-time interactive OAuth login, and you must bind-mount ~/.codex (→ /home/aicode/.codex in the container) so that login survives container recreates:

bash
docker run -it \  -v "$HOME/.codex:/home/aicode/.codex" \  psyb0t/codexbox:latest \  login --device-auth

This prints a URL + a short code. Open the URL in any browser, enter the code, approve — codex writes OAuth tokens to $CODEX_HOME/auth.json (auth_mode is the OAuth/chatgpt variant, not apikey). Every later docker run against that same bind-mounted ~/.codex reuses the login and bills against the subscription, no OPENAI_API_KEY needed:

bash
docker run --rm \  -v "$HOME/.codex:/home/aicode/.codex" \  psyb0t/codexbox:latest \  exec "say HELLO"

This only works if ~/.codex is bind-mounted. Without it, the login lives inside the throwaway container's filesystem and is gone the moment the container is removed — you'd have to re-run the OAuth flow every single time. If OPENAI_API_KEY is also set in the environment once a subscription login exists, it is not used to overwrite it — an existing OAuth login always wins over the API-key seeding step. codex login status (passed straight through) reports which mode is currently active; codex logout clears it.

Model & reasoning effort

Codex has no fixed default model slug — availability is server-driven AND depends on how you authenticated:

  • ChatGPT subscription — the GPT-5.6 family: gpt-5.6-luna (fastest + cheapest — good for tests), gpt-5.6-terra (balanced), gpt-5.6-sol (flagship; the account default). The *-codex / *-codex-mini slugs are rejected on a ChatGPT account (400 "not supported").
  • API key — the API catalog: gpt-5.1-codex, gpt-5-codex, gpt-5.1-codex-mini (small), etc.

Pass a model with -m / --model (passthrough) or set CODEXBOX_MODEL / the model field on /run and /openai/v1/chat/completions.

Reasoning effort maps to codex's model_reasoning_effort config key (-c model_reasoning_effort=<level>). Levels: none, minimal, low, medium, high, xhigh, max (default medium). Exposed as the thinking field on the API and the /effort command in telegram — same shape as the other aicodebox children.

System prompts & tool control

The canonical /run knobs are honored — codex just exposes them differently than pi/claude:

  • systemPrompt → replaces the built-in system prompt (-c instructions=…).
  • appendSystemPrompt → appends a developer-role message (-c developer_instructions=…).
  • noTools → drops the shell/exec + web-search tools and runs the sandbox read-only, so the agent answers without acting. (codex keeps apply_patch/update_plan tool specs that can't be config-removed, but read-only neuters them — the closest codex has to pi/claude --no-tools.)
  • toolsAllowlist → not supported: codex has no name-based built-in tool allowlist (only per-MCP-server enabled_tools). It is ignored with a warning.
  • Session: a call with neither resume nor noContinue continues the top-level Codex exec session pinned to that canonical workspace. The first call starts a persistent root session; later calls resume its exact ID, so a newer subagent rollout cannot steal continuation. Existing workspaces migrate their newest top-level exec rollout automatically. resume targets and re-pins a specific session ID; noContinue runs ephemerally without changing the pin.

Agent integrations

The skill works in any agent that reads .agents/skills/ (such as peen), and installs natively in the clients below.

Claude Code

bash
claude plugin marketplace add psyb0t/agentsclaude plugin install codexbox@psyb0t

Claude Code prompts for the codexbox URL and, if the API/MCP tokens are set on the server, the matching bearer tokens — sensitive values are stored in your OS keychain.

Codex

bash
codex plugin marketplace add psyb0t/agentscodex plugin add codexbox@psyb0t

Installed via the marketplace, the skill is invoked as $codexbox:codexbox. Codex also picks the skill up automatically, with no install, in any repo containing .agents/skills/ — there it's invoked as plain $codexbox.

OpenClaw

The skill is published to ClawHub on every release:

bash
openclaw skills install @psyb0t/codexbox

For MCP clients that speak local stdio, the @psyb0t/codexbox plugin bridges to a running box's /mcp endpoint:

bash
openclaw plugins install clawhub:@psyb0t/codexbox

Then set CODEXBOX_URL (and CODEXBOX_MCP_MODE_TOKEN if the server was started with it set).

Development

Requires psyb0t/docker-aicodebox checked out next to this repo (../docker-aicodebox).

bash
make help        # list targetsmake build-base  # build aicodebox-base from ../docker-aicodeboxmake build       # build codexbox:local on top of itmake build-full  # build + tag the full toolchain variantmake build-all   # build both variantsmake test        # run the full e2e suite (needs .env.test)make test-image-select # hermetic installer/wrapper variant regressionmake test-full-image   # build full and check every advertised toolmake clean       # remove built images

Tests

End-to-end tests build the image and run it against a real OpenAI/codex endpoint. Telegram tests use psyb0t/telethon-plus as a real MTProto userbot.

bash
cp .env.test.example .env.test$EDITOR .env.test   # fill in OPENAI_API_KEY and optionally Telegram credsmake test

Telegram tests auto-skip if AICODEBOX_TELEGRAM_MODE_TOKEN is empty. Everything else only needs OPENAI_API_KEY (and a real ChatGPT-subscription login, if you also want the subscription auth path exercised).

make test-image-select needs neither credentials nor a Docker daemon. It proves CODEXBOX_FULL=0|1 selects, pulls, and bakes the same image. make test-full-image builds latest-full and checks its variant marker, Codex, pinned Go/Python versions, and the advertised CLI matrix.

License

WTFPL — see LICENSE. Do what the fuck you want.

Third-party components bundled in the published images (Codex, and — full image only — Terraform, gh, kubectl, Helm, golangci-lint) keep their own licenses; see THIRD_PARTY.md.

來源:README.md,提交 e1c2bfe

工具

0
SourceWeft 曾在隔離沙箱中以無憑證方式啟動該軟體包一次,以列出其工具,但未能完成:該軟體包類型無法在沙箱中執行。

版本歷史

9
  1. v0.7.6最新Oct 22, 2026
  2. v0.7.5Oct 20, 2026
  3. v0.7.4Oct 20, 2026
  4. v0.7.3Oct 17, 2026
  5. v0.7.2Oct 12, 2026
  6. v0.7.1Oct 10, 2026
  7. v0.7.0Oct 7, 2026
  8. v0.6.5Sep 23, 2026
  9. v0.6.3Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分