Instabox 基本活用

Instabox を、手元の Codex / DSH から開発・検証を進めるための Linux 作業機として使う。手元で指示・レビューし、必要なコマンドやサーバーをリモートで動かす構成を基本候補にする。用途に応じてブラウザ付きデスクトップも選ぶ。

ローカル司令・クラウド内の開発継続・外部での仕事と復旧の管理から、検証タスクに合う仮案を選んで実験する場合は Instabox 開発パターン実験 を使う。この skill は接続・基本運用を担当する。

公式資料を入口にする

β版で機能・コマンド・制限が変わるため、利用の都度 公式 Docs の目次を読み、今回必要なページだけを辿る。下記リンクは入口であり、固定された機能一覧ではない。新機能や移動したページは現行の目次から探す。

判断・操作	読む資料
導入、ログイン、最初の作業機	Quick start
永続化、休止・停止、タイムアウト、ラベル、Vault	Concepts、Machines
CLI のコマンドとフラグ	CLI reference と利用中 CLI の該当 --help
SSH、証明書・トークン、転送	Connecting over SSH
スナップショット保存・複製	Snapshots
Web プレビュー、公開解除	Public ports
Linux デスクトップ、画面操作、閲覧リンク	Desktop
自動化・アプリ組み込み	API keys and SDK、Integrate、SDK reference、API overview
現在の上限、費用、変更履歴	Limits、Pricing、Changelog とアカウントの実表示

• 料金、無料枠、台数・容量、テンプレート、既定タイムアウト、SDK シグネチャをこの skill に転記して固定しない。利用中 CLI / SDK の版とサーバーの対応機能も照合する。
• HTML が instabox needs JavaScript だけなら本文を読めていない。利用可能なブラウザで描画後のページを読む。ページの Copy page as Markdown も使える。取得できなければ未確認と伝え、記憶だけで変更操作を組み立てない。
• 公式が配布するエージェント用スキルも、現行資料から必要なものを確認する。内容をここへ複製せず、導入処理が CLI やローカルのスキル設定も変更するか確認する。

作業の進め方

1. 目的と対象を絞る。 単発のビルド・テスト、配布物の新規導入、長時間ジョブ、Web / GUI 確認、環境再利用のどれかを依頼から判断する。使うリポジトリ・配布物、必要なランタイム、回収物、終了後に残すものを整理する。既存の認証方法と作業機を確認し、使える既存機があれば再利用を検討する。クリーン導入検証には既存設定のない環境を選ぶ。
2. 実行場所を明確にする。 手元の OS と Instabox の Linux を分け、編集・Git・依存導入・ビルドをどちらで行うか決める。Codex アプリを開いているだけでは実行先は変わらないため、SSH / CLI / SDK / API の接続を用意する。Linux の結果だけで macOS / Windows Desktop の互換性を確認済みとしない。
3. 必要な環境を準備する。 Quick start と CLI のヘルプで現行の導入・認証手順を確認する。未導入なら公式の配布方法を使う。既存機の状態、テンプレート、アカウント上限を確認してから、目的に合う作業機を選ぶ。名前・非秘密のラベルで用途を識別し、タイムアウト時の休止 / 削除とアイドル休止を作業時間に合わせる。長時間ジョブでは自動休止が処理に与える影響を確認する。
4. 接続して実行する。 基本は CLI または SSH。繰り返す自動化・サービスへの組み込みで SDK / API が必要になったら該当資料を読む。作業機 ID、OS・アーキテクチャ、作業ディレクトリ、ツール版を確認し、必要なソースや配布物だけを渡す。実行結果は stdout / stderr と終了コードで判定する。長時間ジョブは切断後も追跡できる形で実行し、ログと成果物を永続領域へ保存する。
5. 変更操作の完了を確認する。 作成・起動・休止などの operation は成功 / 失敗まで追い、同じ作業機への次の状態変更を重ねない。応答が途切れたら作業機と operation の状態を先に照会し、作成・削除・実行を無条件で再送しない。API 自動化では現行の冪等性とエラー仕様も確認する。
6. 結果を回収して後片付けする。 ログ、テスト結果、配布物、必要な画面を回収してから、依頼の保持方針に沿って休止・停止・削除する。方針がなければ成果を保持して休止を基本にし、削除を推測しない。今回だけ作った公開ポート・閲覧リンク・SSH トークンは不要になったら解除・失効させる。既存の接続や他の作業を巻き込まない。

CLI が利用可能なら、調査の入口は次のようにする。変更操作は今回必要な資料とヘルプを読んでから組み立てる。

command -v instabox
instabox --help
instabox ls --json
instabox templates --json
instabox usage --json

接続と Web / GUI 確認

• DSH Web など開発用の管理画面は、まず SSH のローカルポート転送を候補にする。SSH の現行の対応範囲とホスト鍵の検証方法を確認し、検証を無効化して接続しない。
• 外部共有・Webhook など公開 URL が必要なら Public ports を読む。公開はサービス全体への外部アクセスを許すため、公開する対象と認証を確認する。URL を知ること自体を認証にしない。
• ブラウザ付きデスクトップは Web UI や Linux GUI の確認に使う。閲覧リンクの制御権・期限・失効方法は Desktop の現行仕様を確認する。
• CLI の SSH、証明書、トークンは用途に合う方式を選ぶ。今回だけのトークンには必要な期間を設定し、接続文字列を資格情報として扱う。秘密値をチャットやログへ出さない。

状態と再利用で押さえること

以下は操作を選ぶ判断軸であり、実行時は Concepts / Machines / Snapshots で再確認する。

• 休止（Pause / suspend） はファイル・メモリ・プロセスを保持する。ただし復元に失敗して新規起動になる場合があるため、再開後はジョブとサービスの生存を確認する。
• 停止（Stop） は永続ファイルを保持し、メモリ・プロセスを失う。次回起動後はサービスを起動し直す。削除はディスクも失う。
• アイドル休止・手動休止・タイムアウト・停止 を区別する。アクセスによる自動再開条件と再開後のタイムアウトを確認し、常に自動復帰すると仮定しない。
• スナップショット は環境の複製用で、実行中プロセスの保存ではない。保存に伴う停止や、実行中保存の条件を確認し、必要な出力を先に書き出す。
• 再利用する原本はツール導入後・ログイン前の状態を基本にする。通常のスナップショットには home、workspace、保存済みのサインイン情報も入り得る。--root-only などの除外範囲は現行資料で確認し、別の場所へ保存した秘密まで除去されると考えない。
• Vault は起動・再開時などに秘密を投入し、ファイル型の値はスナップショットにも入り得る。検証機に秘密が不要なら現行の --no-vault を検討する。必要なら投入先を selector などで絞る。API キーや .env、既存の Codex / DSH / Git / SSH 認証ストアを環境転送に混ぜない。

Codex / DSH と組み合わせるとき

• CLI ジョブや DSH Host / Web と作業リポジトリを Linux 側へ置き、手元から指示・確認する構成を基本候補にする。既存のモデル・認証・承認・sandbox 設定は依頼なしに変更しない。
• 配布物の新規導入検証では対象版を固定し、認証情報を含まない環境へ実際の配布物を導入する。インストール成功に加え、起動・画面・必要な実操作を確認する。DSH 固有の手順は対象リポジトリの開発ルールと公式資料に従う。
• Git 操作の動作テストには一時リポジトリとローカル bare remote を使う。ユーザーの作業リポジトリを動作テスト先にしない。通常の開発作業は、その依頼で指定されたリポジトリと範囲で行う。

完了報告

対象の作業機、確認したツール版と公式資料、実行結果・成果物、残した状態、公開・接続の後片付け、未検証の範囲を短く伝える。過去のチャットの上限・稼働状態・成功例を今回の実測として扱わない。