OrchestratorInc

Multica と Paperclip 権限の既定をソースから比較してみた Claude Code や Codex を並行して動かし始めると、まとめて管理する道具が欲しくなります。候補に挙がる Multica と Paperclip は、GitHub でそれぞれ約 5.5 万と約 11 万のスターを集めています（2026-11-04）。 この記事では、この 2 つに対照として Orchestrator.inc を加え、CLI が出す権限の確認を既定でどう扱うかをソースから比較します。最後に、動かす前に確認したい 4 点を挙げます。 執筆時点では導入実行は行っていません。ソース・公式文書・issue を元にした比較整理です。 ! 参照した版（いずれも 2026-11-04 時点） Multica: v0.8.0（コミット 9b1ab4f） Paperclip: db9be4c（権限の経路は cf51936） Orchestrator.inc: a1fe965e 挙動の話は「ソース上はそう読める」「文書にそう書かれている」の範囲です。ソースへのリンクは版（コミット）を固定した形式で、行が分かるものは行番号を付けています。版が進んでも同じ箇所を指します。 3 つの道具は何を管理するか Multica と Paperclip では、人が各エージェントの画面を見ている必要はありません。課題（作業の依頼と進み具合を記録する単位）を作ってエージェントに割り当て、人は結果を確認します。Orchestrator.inc では、統括役のエージェントが計画を立て、作業ごとにエージェントを起動します。 同様の仕組みは OpenAI の Symphony にもあります。OpenAI は、多くの人が無理なく見られるのは同時に 3〜5 セッションだと書き、開いた課題ごとにワークスペース（エージェントが作業するディレクトリ）とエージェントを割り当てる仕組みにしました（OpenAI の記事）。 管理する対象は、3 つで異なります。 Multica は作業の割り当てを管理します。課題を割り当て、経過をコメントで返し、結果について人のレビューを求めます。Claude Code・Codex など 26 の CLI に対応します。実行は手元の常駐プロセスで、Docker か Helm でセルフホストもできます（README） Paperclip は組織の運営まで扱います。組織図・目標・予算・承認・定期実行を持ち、コード以外の仕事も扱います。公式の説明は、公開時の「人間ゼロの会社」から、仕事でエージェントを管理するアプリに変わりました（README） Orchestrator.inc はコード開発向けです。作業ごとに worktree（1 つのリポジトリから作業ディレクトリを複数作る Git の仕組み）で動かし、CI の失敗やレビューの指摘を担当のエージェントに返します（README） なぜ権限の既定を比較するのか 課題を割り当てて任せる使い方では、CLI の画面の前に人がいません。そのため、CLI が出す権限の確認に誰が答えるか が、道具ごとに決められています。 Claude Code では、作業ディレクトリ内の読み取りは確認が要らず、Bash・書き込み・Web 取得などは確認が要ります（permissions）。bypassPermissions は、この確認をすべて許可するモードです。 非対話の claude -p では、確認に答える人がいません。許可の設定や hook など、承認する仕組みがなければ、確認の要る呼び出しは拒否されます（headless、permission-modes）。 Codex が確認を出すかどうかは、承認の方針（approval_policy）とサンドボックス（sandbox_mode。workspace-write や danger-full-access など）の組み合わせで決まります。両方を無効にする引数が --dangerously-bypass-approvals-and-sandbox です。 確認への答え方は 3 つに分かれます。 道具がすべて許可する（以下「全許可」。すべて許可するモードで CLI を起動する） 人に求める（確認を画面に出して待つ） 拒否して先へ進む（許可していない呼び出しは拒否され、エージェントは続ける） Anthropic の文書は、bypassPermissions を隔離した環境でだけ使うよう書いています。以下では、全許可を無人で動かすための設計として扱います。Multica と Paperclip の節では、最初に結論を書き、続けて、公式文書での位置づけと推奨される隔離を示します。 Multica は Claude Code を全許可で起動し、隔離の責任は利用者が担う Multica は Claude Code を全許可で起動し、利用者の引数では変えられません。実行中の権限の確認は人に表示されず、人は課題の結果をレビューします。 公式の security-model 文書は、ファイルの隔離を保証しないこと、個人アカウントで動かせば SSH 鍵も読めることを書き、専用ユーザー・コンテナ・VM で動かすよう勧めています（security-model.mdx#L14-L28）。この文書は、隔離を利用者の責任とする前提で書かれています。 根拠は v0.8.0 のソースです。 Claude Code を -p と --permission-mode bypassPermissions で起動します（claude.go#L1150、#L1167） Codex の実行と変更の承認要求は自動で受け入れます（codex.go）。Windows での既定のサンドボックスは danger-full-access です（codex_sandbox.go）。ほかの OS の既定は調べていません 人の承認を挟む機能の提案は未解決です（#9149） データとライセンスの既定は次のとおりです。 セルフホストした API サーバーは、日次の匿名テレメトリーを既定で送り、DO_NOT_TRACK=1 で止まります（SELF_HOSTING.md#L21） 課題・コメント・チャット・添付・エージェントの進捗報告は、Multica 側に保存されます。自分のサーバーに保存したい場合はセルフホストになります（公式 FAQ。サーバーは Docker 前提、SELF_HOSTING.md） ライセンスは Apache 2.0 に条件を加えた独自のもので、README は source-available と書きます。組織の中ではセルフホストを含めて無料、社外への提供と製品への組み込みは商用ライセンスです（公式 FAQ） Paperclip はどの経路でも、既定で確認をスキップする Paperclip は、どの実行経路でも既定は全許可です。無効にするための設定は経路によって異なり、画面のスイッチが効かない経路もあります。人の判断を求める場面は雇用・戦略・支出などの統治の承認で、費用は予算の上限で抑える設計です。 公式文書は、確認をスキップする設定を、確認に答えられない無人の実行に必要なものと説明します（claude-local.md#L38）。全許可でも、会社の権限・統治の承認・Runner のワークスペースの隔離は別途有効だと説明しています（Runner の README#L509-L511）。 3 つの経路と既定 Claude のエージェントの実行には 3 つの経路があり、有効な設定が異なります。Paperclip Runner は Paperclip 自身の実行基盤で、ワークスペースを隔離して動かします。ACP（Agent Client Protocol）は、エディタとエージェントをつなぐ標準です。 経路 選ばれる条件 有効な設定 既定 既定から変えたときの挙動 Paperclip Runner Linux・macOS の新しい Claude エージェント（自動） acpxPermissionMode approve-all 作業の画面のカードに確認が出て待つ。応答先がなければ approval_required で止まる（README） ACP claude_local の既定のエンジン permissionMode approve-all 答えられない確認は nonInteractivePermissions（既定 deny）に従い拒否か失敗 CLI engine=cli を明示したとき dangerouslySkipPermissions true 権限の引数を渡さず、確認の要る呼び出しは拒否されて先へ進む 経路の分岐は execute.ts#L424 にあり、ACP を選んだ場合はこの行で ACP の処理を呼び出し、CLI の処理は実行されません。 どれもエージェントごとの設定で、会社全体の設定は見つかりませんでした。Runner は Linux（glibc）と macOS だけで、Windows のホストは ACP か CLI になります（agent-runner.ts#L32-L38）。 確認をスキップする設定の既定を false にする PR #16867（2026-10-19）は、まだ統合されていません。逆に、既定を全許可へ揃える #13693 は 2026-09-19 に統合されました。 設定を既定から変えたときの挙動 確認をスキップする設定を既定から変えた場合を、経路ごとにソースで追うと次のとおりです。 ACP: 画面の「Skip permissions」（dangerouslySkipPermissions）をオフにしても、全許可のままです。ACP の経路はこの設定を実行に使わず、実行に使う permissionMode は Claude の設定スキーマにありません（config-schema.ts）。画面のスイッチを見ただけでは、実際の挙動は分かりません CLI: 無効にすると権限の引数を何も渡しません（permissions.ts#L12）。Claude Code の公式文書によれば、v2.1.302 以降では確認の要る呼び出しが拒否され、Claude は拒否を受けたまま処理を続けます。承認を待ち続けたという報告（#10679）もあります。どちらの場合も、確認の要る操作は実行されません Runner: acpxPermissionMode を approve-all 以外にすると、確認が作業の画面のカードに表示されます。確認を人に求める仕組みは、3 経路のうちこの経路にだけあります。ただし、Claude で実際に動作するかは、issue からも裏づけが取れていません 統治の承認のページ（雇用・戦略・支出）の説明には、どの経路についても権限の確認は含まれていません（approvals.md）。 CLI で無効にすると、確認の要る操作が実行されなくても、成功と記録されるおそれがあります（推測）。Paperclip は、終了コードか is_error が失敗を示すときだけ失敗と判定するためです（execute.ts#L1149-L1152）。スキップする引数が効かなかった古い版では、権限で何もできずに終わった実行が成功と記録された報告があります（#3148）。 Codex で対応する dangerouslyBypassApprovalsAndSandbox も、CLI の既定は true です（codex-local の index.ts#L15）。無効にすると workspace-write のサンドボックスで動き、ネットワークは許可したままです。このとき確認がどう扱われるかは調べていません。 ACP はこの設定を読まず、既定は approve-all です。Runner は承認の方針を never（確認を出さない）だけに限り、作業ディレクトリの限定とネットワークの遮断は Paperclip の側で行います。 定額プランと予算の上限 ソースでは、Paperclip は定額分の費用を 0 として計上します。このため 定額プランでは予算の上限が効かない と読めます（budget-exposure.ts）。予算の上限での停止を前提にするなら、先に自分の課金形態を確認してください。 セキュリティ勧告とライセンス 公開されているセキュリティ勧告は 12 件で、うち critical は 5 件です（Security Advisories、2026-11-04 時点）。Multica と Orchestrator.inc の勧告の件数は、この記事では調べていません。 Oasis Security は 2026-08-05 に 3 件の重大な脆弱性を公表しました。CVE-2026-41679 は CVSS 10.0 で、修正は v2026.416.0 です（Oasis Security）。 ライセンスは MIT で、匿名の利用統計を集めると README に書いています。 Orchestrator.inc は Claude Code に権限の引数を追加しない Orchestrator.inc は、自身の権限の方針が既定（default）のままなら Claude Code に権限の引数を追加しません（command.go）。確認が出ると hook（決まった出来事で外の処理を呼ぶ Claude Code の仕組み）で検知します。作業担当のセッションでは、hook は許可や拒否の応答を返しません（hooks.go）。 ただし、確認に答える人がいないレビュー担当のセッションでは、hook が許可か拒否を返します。作業担当の Claude Code の確認は残り、その確認に人がどこで答えるかは調べていません。 Codex は扱いが異なり、方針が acceptEdits か auto のとき以外は、既定の方針も含めて --dangerously-bypass-approvals-and-sandbox で起動します（同じ command.go）。 権限の既定以外に、次の 2 点があります。 使用状況の共有は既定で有効で、GitHub のユーザー名が付くことがあります（telemetry.md） 運営の集計では、v0.14.3 の 7 日間に spawn（エージェントの起動）を試した 589 件中 171 件（29%）が失敗を経験しました（#7024）。主な原因は独自プロバイダの確認で、通常の利用にどれだけ当たるかは分かりません 3 者は、隔離の責任を誰が担うかが異なる 項目 Multica Paperclip Orchestrator.inc Claude Code の既定 全許可（変えられない） 全許可（3 経路とも） 権限の引数を追加しない Codex の既定 承認を自動で受ける 全許可（Runner は never） 承認とサンドボックスを無効にする（acceptEdits・auto を除く） 確認を人に求める仕組み なし（提案は未解決） Claude は Runner で設定を変えれば作業の画面に出る（動作は未検証）。Codex は Runner でも never Claude の確認を hook で検知（答える場所は未調査） 隔離（公式の説明） 専用ユーザー・コンテナ・VM を勧める Runner はワークスペースを隔離する（ACP・CLI は未調査） この記事では未調査 人が確認する場面 課題の結果（レビュー） 統治の承認 Claude Code の確認 Codex の承認を、Multica と Paperclip は既定で人に求めません。Orchestrator.inc も、既定の方針では承認とサンドボックスを無効にします。Claude Code の確認は、Multica と Paperclip が既定でスキップします。確認を人に求めないなら、Claude Code や Codex が何を読み書きできるかは、実行環境の隔離で決まります。 Multica では隔離の責任を利用者が担い、Paperclip Runner では道具の側でワークスペースを隔離します。Paperclip の ACP と CLI の経路での隔離は調べていません。Orchestrator.inc については、Codex 側の隔離を誰が担うかも、道具自身の隔離の説明も調べていません。 この比較で分からないこと この比較は、道具の効果を測ったものではありません。効果について調べると、次のことが分かりました。 効果を測った独立の評価は、調べた範囲では 3 つとも見つかりませんでした CooperBench（arXiv 2601.13295）では、対話で協調すると成功率が単独より平均 30% 落ちました。ただし課題を介して分担する使い方は測っていません 道具は入れ替わります。Vibe Kanban の運営会社は 2026-04-10 に閉鎖し（告知）、Gas Town の作者 Steve Yegge は再利用できる仕組みをやめて自分専用の道具を作っています（本人の論考） まとめと、動かす前に確認したい 4 点 管理する対象: Multica は作業の割り当て、Paperclip は組織の運営、Orchestrator.inc はコード開発です 権限の既定: Multica は Claude Code を全許可に固定し、Paperclip はどの経路も全許可、Orchestrator.inc は既定の方針では Claude Code の確認を残します 隔離: 実行中の確認を人に求めない道具では、Claude Code や Codex の権限を、実行環境の隔離で制限することになります。その責任を道具と利用者のどちらが担うかは、道具ごとに異なります 既定のまま動かす前に、次の 4 点を確認してください。 権限の既定: Claude Code と Codex をどのモードで起動するか、変えられるか、どの設定が実際に効くか。CLI を起動するソースの箇所で確認できます 隔離の責任は誰が担うか: 公式が勧める隔離は何か、道具の側で隔離するか。security-model や Runner の README に記載があります 予算の上限が効く課金形態: 定額プランか従量課金か。予算の上限が効く条件は、費用を集計するソースで確認できます データの保存先とライセンス: セルフホストの可否、テレメトリーの既定、社外へ提供するときの条件。README と公式 FAQ に記載があります 実際に使う場合は、隔離した環境で動かしてください。既定は版で変わり、とくに Paperclip の PR #16867 が統合されると、この記事の既定の話は変わります。 ! Windows ネイティブで動かす場合（権限の既定とは別の、Windows に固有の未解決の issue。2026-11-04 時点） Paperclip: 定額プランの接続が 2026.1023.0 から使えない（#17968）。Paperclip Runner も対応外 Multica: 成功した実行を、ファイルロックで失敗と報告することがある（#7548） Orchestrator.inc: 未署名のため Smart App Control に止められる（#7232） 参照一覧 Multica（v0.8.0）: claude.go#L1150、claude.go#L1167、codex.go、codex_sandbox.go、security-model.mdx#L14-L28、SELF_HOSTING.md Paperclip（cf51936）: execute.ts#L424、execute.ts#L1149-L1152、permissions.ts#L12、constants.ts#L3-L4、config-schema.ts、config-fields.tsx#L245-L262、agent-runner-selection.ts#L79、agent-runner.ts#L32-L38、permission-policy.ts、codex-local の index.ts#L15、claude-local.md#L38、approvals.md、Runner の README#L509-L511、同#L521-L534、DEVELOPING.md#L2886-L2889 Paperclip（db9be4c）: execute.ts#L445、budget-exposure.ts Orchestrator.inc（a1fe965e）: command.go、hooks.go、telemetry.md

yo @Maaztwts @agent_wrapper installed Orchestrator using rpm on my tumbleweed. The KDE start menu has weird copy which I think isn't supposed to be there. already opened an issue here: agent-orchestrator#7834 t.co

@LShivkumarreddy @useOrchestrator hi @LShivkumarreddy, this should not be happening Best way to report this issue would be to run an agent and ask it to use our bug triage skill to file a detailed bug report (it can refer codebase and actual symptoms while filing the bug) skill: github.com/OrchestratorInc/agent-orchestrator/blo… that said, DMing you to debug this further

Open source, local-first, and works with the agents you already use. Plus a very good ad. OrchestratorInc/agent-orchestrator

🔗 GitHub: OrchestratorInc/agent-orchestrator --- ✉️ If you’re into AI, ML, agents, and building real systems, join my newsletter (it’s free): dankornas.substack.com

download orchestrator here: orchestrator.inc find us on github: OrchestratorInc/agent-orchestrator

Run Teams of AI Coders Without Branch Collisions Running parallel agents usually creates Git conflicts. This tool gives every worker its own Git worktree branch. Then, a live Kanban board tracks your pull requests and CI runs in real time. #github #opensource OrchestratorInc/agent-orchestrator