Feature request — Official all-in-one Docker image (batteries-included) on GHCR: CCS + supported LLM CLIs + tokless, auto-configured, scheduled rebuilds

[malys]

Problem

The current Dockerfile only installs the Claude Code CLI. But CCS already ships eight pre-configured cross-agent delegation targets (Claude Code, Codex, Grok, Antigravity CLI, opencode, Hermes, Cursor Agent, Kimi) and a Terminal Agents feature that launches those CLIs live in a tab. In the default image, none of those binaries actually exist — delegation and terminal-agent tabs fail until the user manually installs each CLI inside the container.

Users who want the full CCS experience today must build a custom image by hand, re-solving the same install/volume/permission problem every time, and re-doing it on every CCS release.

Proposal

Publish an official "batteries-included" image to GitHub Container Registry (ghcr.io/lexus2016/claude-code-studio) alongside the existing slim one, containing:

1. CCS itself (current build).
2. All LLM CLIs that CCS supports as delegation/terminal agents, pre-installed and on PATH — so Delegate, Terminal agent, and cross-agent sync work out of the box. Reference for a clean multi-CLI install layer: cfal/garcon Dockerfile (installs claude, cursor, amp, factory, codex, opencode, pi via official installers in a single non-root layer).
3. tokless pre-installed into the skills path, so the token-optimization layer is active by default.
   3b . idea: openmemory to synchronize session between agents
   3c . idea:codex-plugin-cc to have a transparent delegation for review
4. Auto-configured volumes + config — data/, workspace/, skills/, plus the per-agent state dirs (~/.claude, ~/.codex, ~/.cursor, etc.) declared and seeded automatically. No manual config.json setup for a first run.

Suggested tags

• :slim — current image (Claude CLI only), unchanged.
• :full / :latest-full — everything above.
• Version-pinned: :full-v7.16.1.

Scheduled rebuilds

A GitHub Actions workflow that rebuilds :full on three triggers, so the bundled tools don't rot between CCS releases:

1. Every CCS release (existing trigger).
2. A weekly schedule: cron — picks up new upstream CLI versions and the latest tokless.
3. Manual workflow_dispatch.

CLI versions passed as ARGs (like garcon's OPENCODE_VERSION) so a rebuild can pin or float each tool, and the build summary records the resolved versions.

Goals

Complete, isolated, optimized image: multi-stage build to keep the runtime layer small, runs as non-root (CCS already does), all agents functional on first docker run, published and auto-updated on GHCR.

Notes / open questions

• Engine mode: the :full image should keep tmux (already in the slim Dockerfile) so the Subscription engine and terminal agents work.
• tokless placement: CCS scans its own skills/ dir → system prompt, and the underlying claude subprocess scans ~/.claude/skills/. The image should make clear which path tokless lands in (or both) so it actually triggers.
• Auth is not baked in — CLIs ship without credentials; users still log in / mount their own tokens at runtime (same as garcon, which wipes installer state before volume init).
• Size trade-off: bundling ~8 CLIs is large; hence a separate :full tag rather than changing the default.

[Lexus2016]

Thank you for the detailed proposal. After careful consideration, we are declining to build and publish an official all-in-one multi-agent container image on GHCR.

Reasons:

1. Licensing and Redistribution: Bundling and redistributing multiple proprietary and vendor-specific CLIs (such as Claude Code, Cursor, Codex, etc.) inside a public container image introduces legal and licensing compliance risks regarding third-party redistribution.
2. Maintenance Overhead and Upstream Breakage: Maintaining 8 distinct third-party CLI tools alongside community plugins and proxies within a single image entails significant maintenance churn. Upstream breaking changes, installer updates, dependency clashes (Node, Python, Rust runtimes), and authentication shifts would result in constant CI pipeline failures disconnected from the studio's own codebase.
3. Security & Supply Chain Risks: Pulling multiple external installers and third-party tools during scheduled rebuilds introduces significant supply-chain exposure for users deploying the official image.
4. Image Footprint: An image bundling 8+ LLM CLIs, diverse runtimes, and dependencies would expand to several gigabytes, compromising quick deployment.
5. Project Focus: Claude Code Studio focuses on providing an efficient, responsive UI and agent workflow engine that operates over host tools (local or remote via SSH), rather than functioning as an operating system or multi-agent bundle distributor.

The official repository will continue to maintain the lightweight, minimal Dockerfile (focused on the studio runtime). Users seeking a multi-agent all-in-one container can build custom images (such as using cfal/garcon or community templates as references) tailored to their specific toolsets.