background-agents
アプリケーションColeMurray/background-agents
コーディングタスクを自動化するためのオープンソースのバックグラウンドエージェントシステム。
概要
バックグラウンドで動作するコーディングエージェントで、PR、レビュー、問題解決などのタスクを自動的に実行します。複数の AI モデルをサポートし、Slack、GitHub、Linear と統合されています。組織内でのシングルテナントデプロイ向けに設計されています。
README プレビュー
# Background Agents: Open-Inspect\n\nAn open-source background agents coding system inspired by\n[Ramp's Inspect](https://builders.ramp.com/post/why-we-built-our-background-agent).\n\n## Overview\n\nOpen-Inspect provides a hosted background coding agent that can:\n\n- Work on tasks in the background while you focus on other things\n- Access full development environments (Node.js, Python, git, browser automation, VS Code)\n- Connect from anywhere — web UI, Slack, GitHub PRs, Linear issues, or webhooks\n- Enable multiplayer sessions where multiple people can collaborate in real time\n- Create PRs with proper commit attribution to the prompting user\n- Run on a schedule — cron jobs, Sentry alerts, and webhook-triggered automations\n- Spawn parallel sub-tasks that work in separate sandboxes simultaneously\n- Use your choice of AI model — Anthropic Claude, OpenAI Codex (via ChatGPT subscription), or\n OpenCode Zen\n\n## Security Model (Single-Tenant Only)\n\n> **Important**: This system is designed for **single-tenant deployment only**, where all users are\n> trusted members of the same organization with access to the same repositories.\n\n### How It Works\n\nThe system uses a shared GitHub App installation for git operations (clone, fetch, push). The\ncontrol plane mints short-lived installation tokens server-side and brokers them to sandboxes\nthrough the git credential helper on demand. This means:\n\n- **All users share the same GitHub App credentials** - The GitHub App must be installed on your\n organization's repositories, and any user of the system can access any repo the App has access to\n- **No per-user repository access validation** - The system does not verify that a user has\n permission to access a specific repository before creating a session\n- **GitHub users' OAuth tokens are used for PR creation** - For GitHub logins, PRs are created using\n the user's GitHub OAuth token, ensuring proper attribution and that they can only create PRs on\n repos the
FAQ (5)
トラブル対応Claude Opus 4.8/5.5でHTTP 400のクラシファイアエラー（'temperature is deprecated'または'tool_choice type tool not supported'）が発生した場合、どのように修正すればよいですか？
packages/slack-bot/src/classifier/index.ts および packages/linear-bot/src/classifier/index.ts にある Slack および Linear の分類器リクエストを更新してください:
1. temperature: 0 を削除してください。Claude Opus 4.7+ はデフォルト以外の temperature 値を拒否します。
2. Opus 5.5 では、tool_choice: { type: "tool", name: "classify_target" } のような強制的なツール選択を tool_choice: { type: "auto" } に置き換えてください。
3. プロンプトで、モデルが classify_target ツールを必ず呼び出すように指示してください。
4. ツール呼び出しを含まないレスポンスに対する既存のツール入力バリデーションとターゲットピッカーのフォールバックは維持してください。
Opus 4.8 は temperature を省略すれば強制的なツール使用で動作します。一方、Opus 5.5 では tool と any の両方の tool-choice タイプがサポートされていないため、auto が必要です。暫定的な回避策として、影響を受けないデフォルトモデルである classification_model = "claude-haiku-4-5" を設定してください。
トラブル対応Slack または Linear から作成された PR が、個人の認証情報ではなく app/bot の GitHub アイデンティティを使用して作成されるのはなぜですか？
これは、Web サインインの Better Auth への移行後に発生したクレデンシャル参照のバグが原因でした。Slack、Linear、GitHub のボットセッションは依然としてレガシーの user_scm_tokens テーブルから OAuth トークンを読み取っていましたが、新しい GitHub トークンは Better Auth の user_identities.access_token テーブルに保存されています。ユーザートークンが見つからなかったため、PR の作成は GitHub App のインストールトークンにフォールバックしました。この修正では、ルートアドミッション時に確立された正規ユーザーとそのユーザーにリンクされた GitHub アカウントを使用して、ボットのサービスプリンシパルを Better Auth の信頼されたサーバー API 経由でルーティングし、GitHub プロファイルを検証し、user_scm_tokens は移行前のクレデンシャルに対するフォールバックとしてのみ維持します。issue #1912 の修正を含むコントロールプレーンのリリースにアップグレードまたはデプロイし、その後、影響を受けるユーザーが Better Auth にリンクされた GitHub アカウントを持っていることを確認してください。
トラブル対応名前を変更したセッションタイトルが、「Load more」ページのサイドバーで元の名前に戻ってしまうのはなぜですか？
これは open-inspect の Web UI における既知のバグで、PR #2404（main にコミット 9eee5a4c02b418fec570581fd85d98e01dbee25e としてマージ済み）により修正されています。根本原因: useSessionRename がセッションごとに1つの共有された楽観的タイトルを保持していたことです。開いているセッションページのヘッダーが確定したリネームに追いつくと、すべてのサブスクライバーの楽観的タイトルがクリアされてしまいました。「Load more」で読み込まれたページのサイドバー行は React の state にのみ存在し、再取得（refetch）が行われないため、古いリネーム前のタイトルにフォールバックしていました。修正方法: そのコミットを含むビルドに更新してください。このコミットでは useSidebarSessions にタイトルオーバーレイ（read オーバーレイと同じ形状）が追加され、リネーム結果から書き込まれ、ページがアンマウントまたは再取得されたときに破棄されます。検証コマンド: npm test -w @open-inspect/web -- src/hooks/use-sidebar-title-reconciliation.test.tsx src/hooks/use-session-rename.test.tsx src/hooks/use-sidebar-sessions.test.tsx --maxWorkers=1（74 件のテストがすべてパスするはずです）。
トラブル対応Fable Modal サンドボックスが古いスナップショットから復元された後、作業内容を復旧するにはどうすればよいですか？
Fable 5.1では、supervisor.restored_from_snapshotはセッションが古いsnapshot_image_idから復元されたことを意味します。復元パスはgit fetchのみを実行し、git checkout、reset、cleanは実行しません。データ損失は通常、Modalの2時間のハードタイムアウトがスナップショット取得前にコンテナを強制終了するか、開いているブラウザタブが非アクティブスナップショットを抑制するか、失敗したスナップショットが暗黙的に以前のイメージを保持し続けることが原因で発生します。
復旧手順:
1. 最後のセッション差分を取得します: GET /sessions/<session_id>/diffを実行するか、Web UIのDiffビューを開きます。session_diffストアにはターン後にキャプチャされた最後の追跡ファイルと未追跡ファイルが含まれており、上限は1ファイルあたり512 KiB、合計1.5 MiBです。消失したファイルが存在する場合は、その差分を再適用してください。
2. Cloudflare Workerログでsandbox.snapshot_savedイベントを検索し、それらのimage_idの値を確認します。より新しいイメージが保存された後に置き換えられていた場合は、可能であればそのイメージから手動で起動または復元してください。
3. snapshot_image_idはセッションごとに1つだけ保持されます。スナップショット履歴テーブルは存在せず、snapshot_saved WebSocketイベントも永続化されません。
再発を防ぐには、長時間のターンや2時間のサンドボックス制限の前にGitへコミットしてプッシュし、開いているブラウザタブが非アクティブスナップショットを生成すると思い込まないようにし、Snapshot failedというログメッセージを調査してください。スナップショット操作は300秒でタイムアウトします。恒久的な修正は「Preserve sandbox state before provider expiry」変更であり、これはハード期限切れの前にプロバイダー中立の最終保存を実行し、設定可能なバッファは最小5分、デフォルト10分です。
トラブル対応Modal Sandboxが無限ループで繰り返し生成され、予期しない課金が発生するのを止めるにはどうすればよいですか？
コントロールプレーンを issue #1894 の修正を含むリリースにアップグレード/デプロイしてください。この修正により、connect watchdog によってすでに失敗状態になったサンドボックスからの fatal レポートが無視されるようになり、circuit breaker がブート失敗をカウントするようになります。これにより、低速な、あるいは失敗する .openinspect/setup.sh がブートサイクルのたびに createSandbox をトリガーするのを防ぎます。即時の回避策として、Modal の予算上限/アラートを設定して、サンドボックス作成の失敗時にループが停止するようにし、その後 setup.sh を最適化してください。具体的には、コストの高いインストールを事前ビルド済みイメージに移すか、依存関係をキャッシュして、connect watchdog がタイムアウトする前にブートが完了するようにします。ログにおいて、setup.complete が setup.start の直後に速やかに続き、exit_code: 0 となっていることを確認してください。