エージェントにサンドボックスを与えるということは、エージェントがどのファイルを操作するかを決定することも意味します。ホストからチェックアウトしたリポジトリを共有したり、タスク専用の作業ディレクトリを作成したり、リポジトリ全体をサンドボックス内に保持したりできます。それぞれの配置によって、人間であるあなたがその仕事にどのように参加するかが変わります。
ローカルエディタで差分を監視しながらエージェントと並行して変更を加えたり、結果を確認している間にエージェントに複数のタスクを処理させる余裕を持たせたりすると良いでしょう。sbx両方をサポートしています。チェックアウトの手順は、担当者により多くの作業を依頼するにつれて変更される可能性があります。
ホストからリポジトリをマウントする
チェックアウトを共有すると、エージェントが既に利用している作業ツリーに組み込まれます。プロジェクトディレクトリからsbx run実行すると、そのディレクトリがサンドボックス内の同じ絶対パスにマウントされます。
$ cd ~/my-project
$ sbx run claude
エージェントがファイルを処理している間、ローカルのエディタでファイルを開いておくと、変更がリアルタイムで表示されます。Gitはどちらの側からでも動作するため、エージェントにコミットを行わせるか、自分でコミットを行うかを選択できます。ホスト上の開発サーバーは、ホストにインストールされているランタイムと依存関係を使用して、ホットリロードによって変更内容を反映できます。
これは、一つのタスクにおける緊密な連携に合致する。調整コストは、その作業ツリーを共有することによって発生します。ブランチを切り替えると、エージェントが参照するファイルが変更され、あなたの編集内容がエージェントの進行中の作業の一部となるためです。担当者が処理を続けている間に、関係のない別のことに切り替えたい場合は、再度チェックアウトする必要があります。
[!NOTE]共有チェックアウトに書き込まれた依存関係も共有されます。esbuildのようなネイティブバイナリを含むパッケージは、Linux Sandbox では動作しても、macOS や Windows ホストでは動作しない場合があります。 ホスト上で再インストールすることで、問題が解決する場合があります。依存関係のインストールは別々に行うか、アプリを常に同じ環境で実行してください。
各タスクに個別の作業ツリーを割り当てる
Gitのワークツリーは、各タスクにディレクトリとブランチを割り当てます。各ワークツリーをそれぞれ専用のサンドボックスにマウントすることができ、元のチェックアウトは他の作業に引き続き利用可能です。エージェントによる編集内容はワークツリーに表示されます。どちらも、ローカルのエディタと開発ツールで検査できます。各タスクにはそれぞれ専用の実行環境が用意されており、準備のためのツールや、作業後のクリーンアップを行うためのサンドボックスとワークツリーも備えられています。
Gitには、リンクされたワークツリーのみをマウントする際の制限があります。.gitファイルはマウントポイント外のメタデータを指しており、エージェントはそれにアクセスできません。ファイルの編集は可能ですが、ステータスの確認、ブランチの作成、コミットはホスト上で行う必要があります。ソフトウェア開発の未来においてもgit status実行することは依然として必要です。
sbxはクローンモードをサポートしており、エージェントはサンドボックス内でGitを利用できる別のチェックアウトを実行できます。 ローカルプロジェクトはそのまま保持されますが、 sbxホストソースを読み取り専用としてマウントし、エージェント用の独立したクローンを作成します。そのブランチの変更と依存関係のインストールは、そのチェックアウト先に保持されます。
結果を持ち帰ることは、引き継ぎ作業となる。サンドボックスが実行されている間は、ホスト上でsbxが追加する Git リモートを介してコミットされたブランチを取得できます。 または、エージェントがリポジトリのリモートにプッシュし、通常のGitワークフローを通じてブランチを取得することもできます。変更内容をチェックアウトに取り込むと、ローカルエディタと開発サーバーに変更内容が反映されます。
プロジェクトをサンドボックス内に留めておく
マウントされていないサンドボックスには、ホストワークスペースディレクトリが接続されていません。リポジトリをその中にクローンすると、サンドボックスにはチェックアウトされたリポジトリとその開発環境が格納されます。ホスト上のプロジェクトコピーは、サンドボックスのチェックアウトとは一切関係がありません。
このワークフローは、リモート開発マシンでの作業に似ています。エージェントはプロジェクト環境に接続し、 sbx execでシェルを開いたり、SSH経由でエディタをサンドボックスに接続したりできます。 変更内容や依存関係のインストールは、ホストとは別に管理されます。作業内容を復元するには、ブランチをGitリモートにプッシュします。
プロジェクトごとに1つのサンドボックスを用意するという考え方は、ここでは有効な思考モデルとなるでしょう。プロジェクトとそのツールは、エージェントセッションやサンドボックスの再起動後も保持されます。エージェントは、担当する機能ごとにワークツリーを作成し、ブランチをプッシュし、レビュー用のプルリクエストを作成できます。別のタスクを開始する際に、別のホストワークツリーやサンドボックスを準備する必要はなく、エージェントは各作業ディレクトリでGitにアクセスできます。クローンモードもこの内部ワークツリー方式をサポートしています。
これらの作業はツールやサービスを共有しているため、サーバーの運用や環境の変更には依然として連携が必要となる。個別のサンドボックスは、タスクが独立した環境と個別のファイルを必要とする場合に役立ちます。ブランチだけでは、1つの作業ディレクトリ内での同時編集を分離することはできません。
その独立性ゆえに、結果を試したいと思ったときに、ある程度の距離感が生まれる。普段お使いのローカルエディタではこれらのファイルは参照できません。また、サンドボックス内で実行されている開発サーバーは、ブラウザからアクセスできるように公開されたポート番号が必要です。
ウェブアプリのプレビューについては、担当者にお問い合わせください。
ポート8080で開発サーバーを起動し、 0 . 0 . 0 . 0 .
次に、ホスト上の別の端末からポートを公開します。
$ sbx ports my-sandbox --publish 8080:8080
ブラウザでhttp://localhost: 8080を開いてください。この方法で対話的に作業することは可能ですが、ファイルシステム上に既に存在するプロジェクトを開く場合よりも手順が多くなります。
環境ファイルを使用すると、セットアップを再現可能にし、コミュニティのgithub-clone Kitのようなものを使用して、作成時にツールを選択してリポジトリをクローンすることができます。 サンドボックスを再構築することで、新鮮な環境が得られます。残しておきたい作業は、まず外部にプッシュまたはコピーしてください。サンドボックスを削除すると、そこにのみ保存されているファイルも削除されます。
ジョブに使用するリポジトリを選択してください
APIの変更には対応するフロントエンドの変更が必要になる場合があり、また別のリポジトリに役立つ参考資料が提供される場合もあります。複数のディレクトリを1つのサンドボックスにマウントでき、参照リポジトリには読み取り専用アクセスを設定できます。ローカルでの編集とプレビューは引き続き利用可能ですが、書き込み可能なチェックアウトごとにブランチと変更の調整が必要です。特定のタスクのためにチェックアウトすると、後でクリーンアップする必要のあるディレクトリが残ります。
jganoff/wspのようなワークスペースマネージャは、タスクに必要なリポジトリを選択的に収集することができます。そのワークスペースを設置することで、エージェントは必要なプロジェクトをまとめて利用できるようになります。これらは独自のGitメタデータを持つ標準的なクローンであるため、マウントされたリンクされたワークツリーとは異なり、エージェントはGitへのアクセス権を保持します。
マウント不要のサンドボックス内にも同じスコープが収まります。必要なリポジトリをそこにクローンし、ワークスペース全体をサンドボックス内に保持します。リポジトリの数と、それらのファイルが保存される場所は、それぞれ別の選択肢です。
作業内容に合わせて選択肢を組み合わせてください。
チェックアウトの場所、サンドボックスの有効期間、およびサンドボックスに含まれるリポジトリは、組み合わせて選択できる項目です。複数のタスクに対応できるプロジェクトサンドボックスを用意しておくことも、特定の作業用に組み立てたワークスペースをマウントすることもできます。あなたにとって最適な方法は、エージェントとより密接に連携したい場合や、エージェントに業務管理の裁量をより多く委ねたい場合などに変わる可能性があります。
Gitワークフローのドキュメントでは、直接マウント、クローンモード、ホストワークツリーの仕組みについて説明しています。
