Devcontainer アドオン

リポジトリに、再現可能で隔離された開発コンテナを用意します。人、エディター、コーディングエージェントのいずれもが使えるコンテナです。DWP v7（パック v7.9.0）では、このアドオンが devcontainer-kit を統合します。これは Deep Work Plan がなくても動作する MIT のプロダクトです。任意のアドオンであり、リポジトリはこれがなくても完全に適合します。

devcontainer-kit が提供するもの

テンプレート。 Dev Containers 仕様に基づき、dck init が一つの固定レイアウトでリポジトリに展開します：.devcontainer/devcontainer.json、docker/local/<service>/Dockerfile、docker/local/docker-compose.yaml、dev.sh。後から再実行すると調整を行い、あなたの編集を上書きすることはありません。既存ファイルへの変更はすべて事前に提示され、同意が必要です。
リポジトリ専用のコンテナ。 Dockerfile はランタイムの公式イメージ（node-24、python-3.13、debian）をダイジェストで固定して起点とし、キットのビルド手順を docker/local/<service>/dck/ にコピーします。共有ベースイメージは一切使いません。
dev.sh と dck。 bash dev.sh up は素のターミナルからコンテナをビルドし、起動し、アタッチします。shell、rebuild、doctor などのコマンドは、VS Code や Cursor の有無を問わず動作します。
Herdr は双方向。 ホストの Herdr は、ループバック専用の SSH サーバーを通じて各コンテナを一台のマシンとしてアタッチし、コンテナは標準のサイドバー（App、Editor、Development、Agents）付きで開きます。すべてのワークスペースとペイン（後から開いたものも含む）は、アプリのパス（既定では /app）で起動します。コンテナ内では herdr-peers により、エージェントがホストや他のコンテナにいるエージェントに問い合わせられます。
dck-dockerfile スキル。 エージェントが依頼に応じてリポジトリのコンテナを作成または再生成し、実際のビルドでそれを証明します。

インストール

git clone --branch v1.1.1 https://github.com/DailybotHQ/devcontainer-kit && ./devcontainer-kit/install.sh
cd your-repo && dck init && bash dev.sh up

要件：Linux または macOS ホスト上の bash 3.2 以降と python3 3.11 以降、そしてコンテナコマンド用の Docker と Compose v2。リリースは、その SHA256SUMS アセットで検証してください。v1.1.1 に固定してください。v0.2.0 はサポート対象外です。

項目	値
プロダクト	`DailybotHQ/devcontainer-kit`、タグ `v1.1.1`、インターフェース 2
レジストリキー	`.dwp/config.json` 内の `devcontainer`
リポジトリごとの設定	`.devcontainer/dck.toml`
検出	`dck doctor --json`

v1.0.0 以降は安定版です。 公開インターフェースはセマンティックバージョニングに従い、互換性のない変更は新しいメジャーバージョンでのみ行われます（ファイルについては、新しいインターフェース番号も伴います）。対象は、dck の動詞とドキュメント化されたフラグおよび終了コード（0 成功、1 失敗、2 使用法、3 設定、4 環境、5 拒否）、dck.toml、ホストプロファイル、dck doctor --json のスキーマ（インターフェース 2）、そしてレンダリング契約、すなわち dck init が書き込み所有するファイル、それが保持する dck:managed マーカーとユーザーブロック、エントリポイントが読み取る環境です。v0.3.7 からの移行で壊れるものはありません。dck init と dck rebuild を実行し、イメージに新しい固定バージョン（herdr-peers v1.1.0、coding-agents-kit v1.1.0、DeepWorkPlan Vim v1.0.1）を反映させてください。

レイヤー

どのコンテナにも開発ツール（git、gh、ripgrep、SSH サーバー、Herdr、herdr-peers）が含まれ、ホストのアカウントをオプトインしない限り、シークレットは一切含まれません。それ以外は、dck.toml で選ぶレイヤーです：

レイヤー	デフォルト	追加されるもの
`agents`	オフ	検証済みリリースから取得する coding-agents-kit と、指定した CLI。各 CLI は専用の永続ボリュームを持ち、さらに `classic`（`claudex`、`codexx`、…）と `providers`（`claude-glm`、`codex-azure`、…）のプリセットが加わります。エージェントはデフォルトで自律モードで動作します。コンテナそのものがサンドボックスです。オプトアウト：サービスの `.env` に `AGENTKIT_PERMISSIONS=ask`。
`editor`	オン	タグで固定した DeepWorkPlan Vim 入りの Neovim。オフにすると素のエディターになります。
`dailybot`	オフ	dailybot アドオン用の Dailybot CLI。

ログイン、gh、Herdr の設定、git の ID は bash dev.sh rebuild の後も保持されます。agents レイヤーを有効にすると、イメージには coding-agents-kit の三つのスキル（agentkit、agentkit-setup、agentkit-orchestrate）も含まれます。これらは起動のたびに各エージェントのスキルディレクトリへリンクされるため、再作成したコンテナでも保持されます。

状態ボリューム（SSH ホスト鍵、~/.ssh、gh のログイン、Herdr クライアントの状態、履歴）の名前は state です。複数のサービスが一つの compose プロジェクトを共有する場合は、dck.toml の [compose] state_volume（または dck init --state-volume NAME）でそれぞれに固有の名前を付けてください。そうしないとすべてのサービスが同じボリュームをマウントし、dck doctor がその旨を報告します。

マシンをまたぐエージェント

v0.2.3 以降、Docker Desktop 上では dck up が手作業なしで双方向のメッシュを構成します。

コンテナとホスト。 コンテナ内のエージェントは、ホスト上、他のすべての dck コンテナ内、そしてホストの Herdr がすでに管理している他のループバックコンテナ内の Herdr エージェントに到達でき、逆方向にも到達できます。すべてのピアは固定されたホスト鍵を持ち、初回利用時に信頼されるものはありません。
任意のホストリスナー。 dck setup は一度だけ、127.0.0.1 上のユーザーレベルの SSH サーバーを提案します。このサーバーは dck の鍵のみを受け付け、launchd（macOS）によって稼働し続けます。すでにループバックのリスナーを動かしている場合は、代わりにホストプロファイルをそちらに向けてください。dck host listener disable で削除できます。
再構築後も保持。 コンテナの Herdr マシンカタログはボリューム上にあるため、bash dev.sh rebuild の後も内部に登録されたすべてのマシンが保持されます。v0.3.2 以降、rebuild、start、restart は up と同じ手順を実行します。コンテナはホストの Herdr に再登録され、ホスト鍵は再固定され、メッシュが再配布されるため、ゼロからビルドしたコンテナもすぐにホストとそのピアに到達できます。
コンテナ内の Codex ペイン。 Codex エージェントが他のマシン上のピアに問い合わせるには、ホストに保存されたコンテナのマシン ID である HERDR_PEERS_SELF が必要です。v0.3.3 以降、キットは登録のたびにその ID を記録し、コンテナのログインシェルがそれをエクスポートするため、エージェントが手作業で設定する必要はありません。不一致は dck doctor が指摘します。v0.3.4 以降、コンテナ自身の Codex 設定は、Codex の起動時の更新チェックとバックグラウンドデーモンをスキップします（キットがすべての CLI のバージョンを固定しているため）。ホストの Codex home や共有プロファイルには一切触れません。
ホストからも返信。 dck setup はホストに検証済みの herdr-peers をインストールするため、ホストでも dck agents と dck ask が使え、ホストのエージェントは herdr-peers reply で応答します。
キットが作成していないコンテナ。 それらがログインに使う公開鍵をホストプロファイルの [ssh] authorized_extra に列挙すれば、それらのコンテナも dck コンテナに到達できます。

ホストとコンテナの両方で coding-agents-kit と組み合わせれば、同じ ak で両側のエージェントを起動できます。

コンテナ内のホストアカウント

コンテナは、ホストですでに持っているアカウントを使えます。git がすでにホストの SSH エージェントを通じて動いているのと同じように、コンテナ内でのログインは不要です。これはオプトインで、設定はあなたのホストプロファイルに置き、リポジトリの dck.toml には決して置きません。

[agents]
host_profiles = true          # 既定は false
host_env_keys = ["ZAI_CODING_API_KEY"]   # 共有する環境変数名の許可リスト

host_profiles を有効にすると、dck up はリポジトリがインストールする CLI のプロファイルだけを共有します。

Claude Code はプロファイルごとの長期トークンで共有します。@default には CLAUDE_CODE_OAUTH_TOKEN、@name には CLAUDE_CODE_OAUTH_TOKEN_<SUFFIX> を使います（接尾辞は大文字にし、A-Z、0-9、_ 以外の文字は _ に置き換えます）。
Codex は認証ファイルで、@default と各プロファイルについて共有します。
キットの env ファイルは読み取り専用で、host_env_keys にある名前だけに絞り込みます。

agentkit の home 全体がマウントされることはなく、ホストの絶対パスを含むプロファイルはスキップされます。読み書き可能で共有した Codex のログインは、二つの書き手から同時に更新される可能性があります。Codex アカウントごとに動かすエージェントは一つにしてください。ホストプロファイルの [agents] default_profile（例：{ claude = "@work3" }）を設定すると、コンテナ内で引数なしの ak claude がその共有アカウントを使います（coding-agents-kit ≥ v0.5.2）。macOS の @default の Claude ログインはキーチェーンに保存されているため、共有できません。v0.3.4 以降は、コンテナのシェルが引数なしの claude や codex もそのアカウントに向けるため、Herdr が復元するペインはログイン画面ではなくそのアカウントで開きます。コンテナ内では、同じ ak <kind> @<profile> がホスト上と同じアカウントで動きます。これにより、リードは ak pick が選んだアカウントをコンテナのレーンに渡せます。詳しくは多数のエージェントを動かすを参照してください。

複数のリポジトリ、一つの compose スタック

v0.3.3 以降、サービスがより大きな compose プロジェクトの一部であるリポジトリ（API、Web アプリ、ワーカー、データベースが一つのプロジェクトを共有する構成）は、dck がレンダリングする内容を手で編集せずにそのプロジェクトに参加できます。変更はすべて追加的です。これらのキーを一つも設定しないリポジトリは、これまでとまったく同じようにレンダリングされます。

一つのプロジェクト、サービスごとに一つの状態ボリューム。 [compose] project は各リポジトリで共有プロジェクトの名前を指定します。state_volume、[compose] networks、[compose] volumes は、各サービスの状態と、スタックのデータボリュームおよびネットワークを分離します。
ユーザーブロック。 dck サービス内の # >>> user:<service> >>> と # <<< user:<service> <<< の間の行はそのまま保持されます。dck がレンダリングしないもの（depends_on、healthcheck）には通常のキーを、dck がレンダリングするキーには x-dck-merge: を使います。dck のマーカーの一部しか含まないファイルは、書き換えられるのではなく、修正方法を示して拒否されます。
ポート文字列。 ssh_port と ports は "${API_PORT:-8000}:8000" のような compose 式を受け付けます。文字列がホスト IP を指定しない限り、127.0.0.1 に留まります。
共有ビルドと独自のランチャー。 [build] context と [build] dockerfile は複数のサービスで共有する Dockerfile に対応します。dev_sh = false はリポジトリ独自の dev.sh を保持します。
ワークスペースのサテライト。 v0.3.5 以降、独自の compose プロジェクトにあるサービスの二つ目のインスタンスは dck を通じて起動・停止します（dck --project P --compose-file F --service S up または down）。そのため、メインのインスタンスと同じホストキー、アカウント、git の ID、Herdr マシンを得られます。up --seed-state-from VOLUME は、ログイン情報だけをその空の状態ボリュームにコピーします。オーバーレイファイルでは、extends に拡張元のファイルを指定する必要があります。
エージェント用の Node。 エージェント自身の Node は /opt/dck/node 配下にあり、イメージの Node を置き換えることはありません。リポジトリのツールがそれを必要とする場合は、[agents] node_first = true で PATH の先頭に置きます。

コンテナ内のホストの SSH 鍵

一部のツールは鍵ファイルだけを読み、転送されたエージェントを無視します。たとえば gh auth login は新しい鍵の生成を提案します。v0.3.2 以降はオプトインできます。設定できるのはホストプロファイルのみです（リポジトリの dck.toml では設定できません。dck setup が一度だけ尋ね、デフォルトは「いいえ」です）：

[ssh]
copy_keys = true              # default false

有効な間、dck up はホストの ~/.ssh を読み取り専用で ~/.ssh_host にバインドし、起動のたびにその id_* 鍵をコンテナの ~/.ssh にコピーして（秘密鍵は 0600）、ホストと同期させます。エージェント転送は変わらず、無効にすると次回の起動時にコピーは削除されます。代償として、ホストの ~/.ssh 全体がコンテナ内から読み取り可能になり、秘密鍵は状態ボリュームに保存されます。

セキュリティのデフォルト

公開されるポートはすべて、dck.toml が bind を設定しない限り 127.0.0.1 にバインドされます。
SSH 経由の git はホストの SSH エージェントを通ります。使うのはそのソケットであり、鍵ファイルも、マウントした ~/.ssh や ~/.gitconfig も使いません（ホストプロファイルで copy_keys を有効にした場合を除きます）。git の ID は dck setup が埋める DCK_GIT_* の値から取得します。
SSH ホスト鍵は実行時にプロジェクトごとのボリュームへ生成され、イメージに焼き込まれることはありません。サーバーは公開鍵のみを受け付け、root ログインもパスワードも許可しません。
テンプレートは cap_add、privileged モード、Docker ソケットのいずれも追加しません。
すべてのダウンロードはバージョンで固定され、チェックサムで検証されます。ベースイメージはダイジェストで固定されます。
あるコンテナのエージェントが他のコンテナに到達できる Herdr メッシュはデフォルトで有効であり、その無効化の方法はキットの脅威モデルに記載されています。ホストリスナーは、実行中のコンテナ内のコードがあなたとしてホスト上でシェルを開くことを可能にします。これはオプトインで、ループバック限定であり、dck の鍵のみを受け付け、dck host listener disable で削除できます。

補足

任意であり、必須となることはありません。リポジトリはオプションアドオンがゼロでも完全に適合します。Linux と macOS のホストがサポートされています。コンテナ間のメッシュには Docker Desktop が必要です。