3行まとめ
どのhostでfiles、credentials、local toolsを使うかを確認します。
read-only、workspace限定、外部toolの扱いを分けます。
diff、command、MCP/API利用を人間が止められる状態にします。
別端末から操作できることと、安全に承認できることは分けて考えます。
- AIコーディングエージェントを別端末から操作するときの本質は、入力画面ではなく「どのホストで、どの権限で、何を承認できるか」です。
- Codex Remote ConnectionsとClaude Remote Controlは、公式にローカル実行を遠隔から継続する仕組みを持ちます。OpenCode serverはHTTP serverを公開できるため、認証、host bind、permission設定を先に固める必要があります。
- 初期導入は、read-only、workspace限定、MCP/APIキー棚卸し、差分レビュー、人間承認、ログ確認を最小単位にしてから広げるのが現実的です。
この記事でわかること
接続先hostのrepository、branch、worktreeを確認します。
移動中に押してよい承認と、戻って確認する承認を分けます。
MCP、API key、private repositoryをどこで止めるかを決めます。
AGENTS.md、runbook、レビューゲートに残す項目を決めます。
仕様比較よりも、実務でどこまで許可するかを先に決めます。
この記事では、直近のX/Twitterで見られた「Claude Code、Codex、OpenCodeをスマホから使いたい」という関心を、実務導入の確認項目に変換します。Xは需要シグナルとしてだけ扱い、仕様や安全性の判断は2026年6月11日に確認した公式ドキュメントをもとにします。
扱う範囲は、Codex Remote Connections、Claude Code Remote Control、OpenCode serverです。どのツールが優れているかを断定する比較ではありません。開発者や小規模チームが、別端末からエージェント作業を見守る、指示する、承認する前に、何を止めておくべきかを整理します。
特に次の判断に使えます。
- ローカル実行を別端末から操作してよいか
- 承認ボタンを移動中に押してよい条件は何か
- MCP、APIキー、private repositoryをどこで止めるか
- OpenCode serverをLAN、VPN、public tunnelのどこに置くか
- チーム導入時にAGENTS.md、runbook、レビューゲートへ何を書くか
前提知識
- 1別端末
指示、確認、承認の入口になります。
- 2接続サービス
Codex Remote Connections、Claude Remote Control、OpenCode serverが入口になります。
- 3実行host
files、credentials、permissions、plugins、local toolsに近い場所です。
- 4外部接続
repository、MCP server、API、browser stateへ影響が広がります。
画面が変わっても、実際に触る境界は実行host側に残ります。
操作端末より実行hostを見る
確認項目
AIコーディングエージェントのリモート操作は、画面共有やチャットUIの話だけではありません。エージェントが動く場所には、ファイルシステム、Git認証、MCP server、APIキー、ブラウザ状態、実行コマンド、ローカル設定があります。別端末から操作できるようになると、作業を止めずに済む一方で、承認判断だけが軽くなりやすい。
公式docsで分けて確認した境界
Codexで見る点
Codexの公式ドキュメントでは、Remote connectionsは接続先ホストのprojects、threads、files、credentials、permissions、plugins、Computer Use、browser setup、local toolsを使うと説明されています。つまり、ChatGPT mobile appから見えているのは軽い操作画面でも、実際には接続先ホストの権限が効いています。
Claude Codeで見る点
Claude CodeのRemote Controlも、Claude appやclaude.ai/codeからローカルセッションを継続できます。ただし実行場所はローカルマシンです。Anthropicの説明では、Remote ControlはローカルセッションがAnthropic APIへoutbound HTTPSで接続し、短命のcredentialを使います。Claude Code on the webとは実行場所が違うため、同じ名前の画面でもリスクは分けて考えます。
OpenCodeで見る点
OpenCode serverはさらに性質が違います。opencode serve はheadless HTTP serverを起動し、OpenAPI endpointを公開します。公式ドキュメント上の既定値は 127.0.0.1:4096 ですが、--hostname や --cors で公開範囲を変えられます。OPENCODE_SERVER_PASSWORD でBasic認証を設定できますが、それだけで安全と言い切れるものではありません。
結果: 最初は「見る、止める、戻す」から始める
- 1見る
差分、command、接続先、credentialの有無を確認します。
- 2止める
workspace外、network、MCP tool callを承認前に止めます。
- 3戻す
feature branch、破棄できるworktree、rollback手順を用意します。
- 4記録する
test結果、承認、PR、ログを後から追える形にします。
迷った操作は進める前に止め、落ち着いてreviewできる環境で確認します。
別端末からAIコーディングを動かすなら、最初の成功条件は「どこからでも作業できる」ではなく、「危ない操作を見落とさず、止められて、戻せる」です。移動中に承認できること自体は便利ですが、承認画面が小さくなるほど、差分、コマンド、接続先、credentialの確認は雑になりやすい。
初期導入のOKラインは、次の4つです。
| 層 | 最初の許可 | 後回しにするもの |
|---|---|---|
| ファイル | workspace内のread、限定write | home directory全体、別repository、秘密情報置き場 |
| コマンド | test、lint、typecheck、read-only git | deploy、release、DB migration、課金API、削除 |
| 外部接続 | 公式Docs、限定domain、read-only API | 任意URL、未審査MCP、顧客DB、管理者API |
| 承認 | 差分とコマンドを見て1回ずつ許可 | まとめてauto approve、恒久的なbypass |
この線引きができない場合、リモート操作はまだ早いです。先にローカルでAGENTS.mdや権限設定を整え、承認しないと進まない状態を作ります。Codexのチーム運用では、Codex subagentsをチームで使う前に のように、並列作業と承認境界を分けて考えると設計しやすくなります。
Codex Remote Connections、Claude Remote Control、OpenCode serverの違い
単純な優劣ではなく、どこで実行され、何を信頼するかで選びます。
3つは同じ「別端末から使う」体験に見えても、実行場所と保護の前提が違います。ここを混ぜると、便利さだけを見て権限を広げてしまいます。
| 方式 | 実行場所 | 主な確認点 |
|---|---|---|
| Codex Remote Connections | Codex Appが動くMacまたはWindows host | host上のproject、credential、permission、plugin、local toolを使う |
| Claude Code Remote Control | Claude Codeのローカルセッション | 明示的な有効化、outbound HTTPS、Team/Enterprise admin toggle、local MCP |
| OpenCode server | opencode serve のHTTP server | bind先、password、CORS、permission config、MCP/OAuth token |
Codex Remote ConnectionsはCodex Appホストを動かす
OpenAIのCodex Remote connections docsでは、ChatGPT mobile appから接続済みのMacまたはWindows上のCodex App hostを操作できると説明されています。できることには、新しいthread開始、既存作業の継続、追加指示、質問への回答、actionの承認、diffやtest resultやterminal outputの確認が含まれます。
確認ポイント
注意点は、セットアップがCodex Appから始まることです。公式docsでは、mobile setupはCodex CLIやIDE Extensionからではなく、Codex App hostから開始するとされています。CLIを遠隔で直接開いている感覚で設計すると、どの設定が効いているのかを誤りやすい。
承認とsandbox
Codex側では、sandbox modeとapproval policyを分けて見ます。公式docsでは、sandbox modeは「技術的に何ができるか」、approval policyは「いつ止まって承認を求めるか」と整理されています。さらにCodex permissions docsでは、:read-only、:workspace、:danger-full-access のprofilesがあり、local command execution以外のsurfaceには別のcontrolがあると説明されています。
最初の設定は、workspace相当の作業範囲に絞り、network accessを必要なときだけ許可する形が扱いやすいです。danger-full-access は、専用VMや検証環境で理由が説明できるときの例外にします。
Claude Remote Controlは明示的に有効化したローカル実行
Claude CodeのRemote Controlは、claude remote-control、claude --remote-control、または /remote-control で有効化します。公式docsでは、既定では明示的に起動したときだけRemote Controlが有効になるとされています。全sessionで有効化する設定もありますが、チームでは最初から既定ONにしないほうが安全です。
接続方式の根拠
接続方式について、Anthropicのdocsは、ローカルClaude Code sessionがoutbound HTTPSでAnthropic APIへ接続し、webまたはmobile clientとのmessageをstreaming connectionで中継すると説明しています。inbound portを開かない点は安心材料ですが、ローカルのMCP server、tools、project configurationを使うことに変わりはありません。
web版との違い
Claude Code on the webとの違いも重要です。Remote Controlはローカルマシンで実行され、Claude Code on the webはAnthropic-managed cloud infrastructureで実行されます。同じclaude.ai/code画面を使っても、社内コードやcredentialがどこにあるか、どのMCP serverに届くかは別物です。
Claude Code security docsでは、Claude Codeはread-only permissionsを既定とし、編集、test実行、command実行など追加actionが必要なときは明示的な許可を求めると説明されています。この性質を活かすなら、移動中の承認は「差分とコマンドが十分に見える場合だけ」に限定します。hooksを使ったレビューゲートは、Claude Code Hooksをチームで使う前に で整理したように、permissionの代替ではなく補助線として扱うのがよいです。
OpenCode serverはserver公開とpassword設定が入口
OpenCode serverは、他の2つよりも「自分で公開面を作る」感覚が強いです。公式docsでは、opencode serve はheadless HTTP serverを起動し、OpenAPI endpointを公開します。既定ではport 4096、hostname 127.0.0.1 とされています。
最小起動例
ローカルだけで試すなら、まず次のように明示的にlocalhostへ縛ります。
OPENCODE_SERVER_PASSWORD="replace-with-long-random-value" \
opencode serve --hostname 127.0.0.1 --port 4096公開前に見るAPI
LAN、VPN、public tunnelへ広げる前に、server APIが何をできるかを確認します。OpenCode server docsには、session一覧、message送信、diff取得、revert、shell command、MCP statusなどのAPIが並んでいます。つまり、serverの公開は「チャット入力欄を外へ出す」だけではありません。作業session、diff、shell、MCP状態へ届く入口を作るということです。
OpenCode permissions docsでは、permission configでactionを allow、ask、deny にできます。公式docsは、多くのpermissionが既定で allow、external_directory と doom_loop が既定で ask と説明しています。ここはCodexやClaude Codeの既定と同じつもりで扱わないほうがよいです。
OpenCodeをチームで扱う場合は、OpenCodeをチームで使う前に の観点と同じく、permission、MCP、GitHub Action、server公開を別々に記録します。
権限設計は接続方式ではなく実行場所から決める
実行hostに何が置かれているかを見て、初期値はaskまたはdeny寄りにします。
リモート操作の設計で最初に書くべき項目は、使うアプリ名ではありません。実行ホストです。
たとえば、同じ「Codexをスマホから操作する」でも、接続先が普段の開発Macなら、GitHub credential、npm token、local env、ブラウザ状態、MCP設定に近い場所で作業します。クラウドの隔離環境なら、hostへの影響は小さくなりますが、GitHub repository、setup script、secret injection、network設定のリスクが出ます。
実行ホストごとに、次の表を作ります。
| 項目 | 記録すること |
|---|---|
| host | 個人PC、社用端末、VM、Codespaces、専用containerなど |
| repository | 対象repo、branch、worktree、write可否 |
| credential | GitHub、package registry、cloud、MCP OAuth、API key |
| command | 自動許可するcommand、毎回承認するcommand、禁止command |
| network | 既定off、domain allowlist、任意接続の可否 |
| rollback | git checkpoint、branch、PR、revert手順 |
この表がない状態で、別端末から承認できるようにすると、承認者は「今どのhostで動いているのか」を毎回思い出す必要があります。運用で人間の記憶に頼るほど、事故は起きやすくなります。
読み取り、編集、コマンド実行を同じ許可にしない
初期許可の考え方
AIエージェントに渡す権限は、最低でもread、edit、command、network、external toolに分けます。
read-onlyなら安全、とは言い切れません。private repository、顧客情報、credentialファイル、社内設計書を読めるなら、外部送信やprompt injectionの影響範囲は広がります。ただし、最初からeditやdeployまで許可するより、read-onlyから始めるほうが監査しやすい。
GitHub連携
GitHub連携は、最初からissue commentやPR作成まで許可せず、read-onlyで現行repositoryだけを見るところから始めます。fine-grained PATやtool allowlistを実装寄りに確認したい場合は、TypeScriptでGitHub read-only MCPサーバーを作る の構成が近いです。
danger-full-accessやbypassは例外扱いにする
Codexの :danger-full-access、Claude Codeのpermission bypass、OpenCodeの広い permission: "allow" は、いずれも作業を速くします。ただし、リモート操作と組み合わせると、承認の摩擦が下がった状態で広い操作が走ります。
例外にする条件
使うなら条件を決めます。
- 対象は専用VM、検証用container、または破棄できるworktreeに限る
- API key、cloud credential、本番DB接続は置かない
- repositoryはfeature branchに限定する
- 作業後にdiff、test、secret scan、依存変更を人間が見る
- 設定を恒久化しない
便利な設定を「今日だけ」のつもりで入れて、そのまま共有configに残るのが一番危ないパターンです。
スマホ操作前のミニマム安全構成
repository、branch、worktree、command、diff範囲を毎回確認します。
1 repository、1 task typeに絞り、review gateとログ保存を置きます。
password、公開範囲、TLS、IP制限、ログ方針を先に決めます。
確認できない項目がある場合は、公開や書き込みを広げない初期値にします。
個人利用、小規模チーム、外部公開に近いOpenCode serverで、最初の線引きは少し変わります。
個人ローカルで試す場合
個人の検証なら、対象repositoryを1つに絞り、git branchを切ってから始めます。CodexやClaude Codeは、workspace内のreadと限定writeにし、networkは必要になったときだけ許可します。OpenCodeは permission を明示し、edit と bash を最初から広く許可しない設定で試します。
承認時には、少なくとも次を見ます。
- どのhostで実行されているか
- どのrepository、branch、worktreeか
- どのcommandが走るか
- diffが想定scopeに収まっているか
- MCPや外部APIを使っていないか
移動中に小さな画面でdiff全体を確認しにくいなら、承認せずに止めるほうがよいです。通知は便利ですが、承認品質を保証しません。
チームで使う場合
チーム導入では、個人の設定をそのまま広げないことが大切です。社内ルールとして、次の3つを分けます。
- 人間が見なくてもよい作業
- 人間が確認してから進める作業
- エージェントに任せない作業
たとえば、format、lint、unit test、read-only調査は1に入りやすい。feature実装、test修正、dependency updateは2です。deploy、本番DB操作、課金設定、IAM変更、secret更新は3から始めるのが無難です。
AGENTS.mdやrunbookには、承認基準を具体的に書きます。「危険そうなら止める」では弱い。git push、npm publish、terraform apply、DB migration、外部API write、MCPのwrite/admin toolなど、止める名前を明記します。
OpenCode serverを外から触る場合
OpenCode serverをLANやVPN越しに使う場合は、次の順に広げます。
127.0.0.1だけで動かす- passwordを設定する
- permissionを
ask寄りにする - VPN内の固定hostだけにする
- CORSと公開domainを必要最小限にする
- ログとsession削除手順を確認する
public tunnelへ出す前に、server APIの一覧を読みます。/session/:id/shell や /mcp など、操作範囲が広いendpointを含むためです。passwordがあるから公開してよい、ではなく、誰が、どこから、何を、どのsessionに対して実行できるかで判断します。
MCP/APIキー/外部ツールをどこで止めるか
- 1MCP server
local MCPとremote MCPを分け、tool callはaskから始めます。
- 2OAuth token
保存場所、scope、失効手順を確認します。
- 3API key
本番DB、cloud、外部SaaSへの権限を最小にします。
- 4private repository
対象repositoryとbranchを限定し、予定外の参照を止めます。
- 5ログ
入力、tool call、承認、結果を後から追える形にします。
外部ツールは便利さより、許可、ask、deny、ログの境界を先に置きます。
リモート操作で一番見落としやすいのは、入力画面ではなく外部ツールです。MCP server、GitHub token、Sentry、Notion、Slack、DB、cloud APIなどは、エージェントの判断範囲を一気に広げます。
OpenCode MCP servers docsでは、local MCPとremote MCPを設定でき、remote MCPのOAuthも扱えます。認証後のtokenは ~/.local/share/opencode/mcp-auth.json に保存されると説明されています。これは便利ですが、実行hostのcredential棚卸しが必要という意味でもあります。
CodexやClaude Codeでも同じです。ローカルMCP serverは、ローカルに置いたcredentialや社内networkに近い場所で動くことがあります。remote MCPは、外部サービスへpromptやtool inputが渡る可能性があります。
MCPを有効化する前に、serverごとに次を記録します。
| 項目 | 確認内容 |
|---|---|
| server種別 | local、remote、stdio、HTTP、SSEなど |
| publisher | 公式、社内、個人、未確認OSS |
| tool一覧 | read、write、delete、admin、billing、deploy |
| credential | OAuth、PAT、API key、環境変数、保存場所 |
| data | prompt、file content、API response、logの送信先 |
| revoke | token削除、OAuth revoke、config無効化の手順 |
read toolだけなら常に安全、という判断もしません。読み取ったコードやissue本文がLLM contextへ入り、さらに別toolの入力になることがあります。未信頼のissue、PR、Docs、MCP outputはprompt injectionの入口として扱います。
承認フローとログはチーム運用の本体
- タスク投入
対象repository、scope、禁止操作を明示します。
- 差分確認
想定scopeを超える変更を止めます。
- 編集/command承認
workspace外、network、MCP tool callを個別に確認します。
- テスト
実行結果と未実行理由を残します。
- PR/ログ
レビュー判断に必要な抜粋と承認履歴を残します。
承認は作業を速くするボタンではなく、止まる条件を実装する場所です。
別端末からの操作で「作業が止まらない」ことを目標にすると、承認が軽くなります。実務では、止まるべきところで止まるほうが価値があります。
承認ポイントは、次の粒度で分けます。
- ファイル編集の開始
- workspace外のread/write
- shell command
- network access
- MCP tool call
- Git操作
- package install
- external API write
- secretやcredentialに触れる可能性がある操作
Codexのdocsでは、sandbox modeとapproval policyは別のcontrolです。Claude Codeのdocsでも、read-onlyから始まり、追加actionで明示的な許可を求める設計が説明されています。OpenCodeではpermission configでallow/ask/denyを決めます。表現は違っても、実務上の問いは同じです。
「この操作は自動で進めてよいか」
承認ログには、最低限次を残します。
- task名
- 実行host
- repository/branch
- 承認したcommand
- 使用したMCP/tool
- 生成diff
- test結果
- 人間が未確認の箇所
ログは監視のためだけではありません。失敗したときに、どの承認が問題だったのかを戻るための材料です。AIコーディングツールの料金や上限も、長いagent session、再試行、tool呼び出しで変わるため、AIコーディングツール料金改定の見方 と合わせて、承認ログと利用量ログを同じ週次レビューで見ると判断しやすくなります。
失敗点
画面が変わっても、実行hostのcredentialやprivate repoには近いままです。
外から入れないことだけで、外部送信やtool利用の安全性は決まりません。
OpenCode serverは公開範囲、CORS、TLS、IP制限も確認します。
toolごとの入力、scope、ログを見ずに広げないようにします。
workspace外、credential、広いdiff、testなしの変更を停止条件にします。
問題は操作端末ではなく、実行hostが何へ届くかを見失うことです。
失敗1: スマホ操作を「安全なUI」と見なす
別端末から操作できることは、安全性の証明ではありません。実行hostが普段の開発環境なら、ローカルcredential、private repo、MCP、ブラウザ状態へ近い。画面がモバイルアプリに変わっても、エージェントが触れる境界はhost側にあります。
失敗2: inbound portがないので安全と判断する
Claude Remote Controlのようにinbound portを開かない設計は重要です。ただし、ローカルsessionが使えるtools、MCP、project configurationのリスクは残ります。接続方式の安全性と、作業権限の安全性は分けて見ます。
失敗3: OpenCode serverにpasswordを付けただけで公開する
OpenCode serverはOpenAPI endpointを持ち、session、message、shell、MCPなどに関係するAPIを公開します。passwordは入口の1つですが、公開host、CORS、VPN、permission、ログ、revoke手順が揃っていないなら、外部公開に近い運用は避けます。
失敗4: MCPを便利ツールとして一括許可する
MCP serverを1つ許可すると、複数のtoolが増えることがあります。read tool、write tool、delete、admin、billing、deployを同じ許可にしないでください。MCP server名ではなく、tool単位で何ができるかを見ます。
失敗5: チーム展開前に「止める条件」を決めない
AIエージェント導入は、成功例より失敗時の止め方が大事です。次の条件を満たしたら止める、と先に決めます。
- 予定外のrepositoryへ触れた
- workspace外のfileへ触れた
- credentialらしき値を読もうとした
- MCP toolの入力にprivate dataが含まれた
- testなしで広いdiffを出した
- 人間が読めない量の変更を一度に出した
- 料金やrequest量が週次上限を超えた
実務で使うなら
- 個人開発
test完了通知、短い方針返信、小さいdiffの承認から始めます。
- 限定タスク
test修正、README更新、lint修正、局所的な型エラー修正に絞ります。
- チーム導入
1 repository、1 task type、review gate、ログ保存を先に固定します。
- 拡張判断
MCP write、複数repository、deployに近い操作は別の承認にします。
最初からfeature開発やdeployまで広げず、戻せる範囲で使い始めます。
個人開発なら、Codex Remote ConnectionsやClaude Remote Controlは「長い作業を止めずに見守る」用途から始めるのがよいです。移動中に実装方針を軽く返す、test完了通知を受ける、diffが小さい修正だけ承認する、といった使い方です。
チームなら、最初の対象を1 repository、1 task typeに絞ります。たとえば、test修正、README更新、lint修正、型エラーの局所修正などです。いきなりfeature開発、複数repository横断、MCP write、deployまで広げない。
1週間の試験運用では、次を見ます。
| 観点 | 見る数字 |
|---|---|
| 品質 | 採用したdiff、差し戻したdiff、追加修正量 |
| 安全性 | 承認回数、拒否回数、危険command候補 |
| 速度 | task完了時間、review時間、待機時間 |
| コスト | session数、モデル利用量、再試行回数 |
| 運用 | ログ欠落、承認理由の不足、AGENTS.md違反 |
この数字が取れないなら、まだチーム展開しないほうがよいです。便利だったかどうかだけでは、継続利用の判断ができません。
セキュリティ・コスト注意
セキュリティは単純な勝敗にせず、組織と実行hostの条件で判断します。
リモート操作のセキュリティは、ツール単体では完結しません。端末の紛失、SSO、MFA、組織policy、VPN、開発hostのcredential管理、MCP serverのpublisher、ログ保持、料金上限まで合わせて設計します。
特に注意するのは次の点です。
- Codex Remote Connectionsは接続先hostのcredentialやlocal toolsを使う
- Codexのpermission profilesはlocal command execution向けで、他surfaceは別control
- Claude Remote Controlはローカル実行とClaude Code on the webを混同しない
- Claude Team/EnterpriseではRemote Controlがadmin policyで無効化される場合がある
- OpenCode serverは既定localhostでも、hostnameやCORSで公開面が変わる
- OpenCodeのpermission defaultはCodex/Claude Codeと同じ前提にしない
- MCP token、OAuth、API keyの保存場所とrevoke手順を確認する
- agent sessionの長期化、再試行、tool呼び出しは料金と上限に効く
スポンサー、無償提供、検証環境提供はありません。本記事は公式ドキュメント確認にもとづく設計ガイドであり、実運用の最終判断は各組織の規程、契約、セキュリティ要件に合わせてください。
FAQ
迷ったら、どのhostで何を実行し、誰がどこで止めるかへ戻ります。
Q. スマホから承認できるなら、レビューもスマホだけで足りますか
足りない場面が多いです。差分が小さく、commandが限定され、test結果が明確なときだけ承認する運用にします。大きなdiff、依存更新、MCP/API利用、deployに近い操作は、落ち着いてreviewできる環境へ戻して確認します。
Q. Codex Remote ConnectionsとClaude Remote Controlは同じ考え方でよいですか
似ていますが同じではありません。どちらもローカル作業を別端末から継続する使い方がありますが、有効化方法、管理者設定、接続方式、permissionの既定、MCPとの関係が違います。共通化するのは「実行host単位で権限を棚卸しする」という運用ルールです。
Q. OpenCode serverをVPN内で使うなら安全ですか
VPNは公開範囲を狭める助けになりますが、それだけで十分ではありません。password、permission、host bind、CORS、MCP、session削除、ログ、token revokeを合わせて確認します。VPN内の利用者が全員同じ権限でよいかも別問題です。
Q. MCPはread-onlyだけなら入れてよいですか
最初の候補にはなります。ただし、read-onlyでもprivate dataをLLM contextへ渡すことがあります。serverのpublisher、tool一覧、送信先、ログ、認証scopeを確認し、対象repositoryやdata typeを絞ります。
Q. チームで最初に作るべきものは何ですか
ツール比較表より先に、承認runbookを作ります。許可するcommand、禁止するcommand、MCPのallowlist、API keyの置き場所、ログの見方、事故時の止め方を書きます。AGENTS.mdには、エージェントへ渡す作業ルールとして短く落とし込みます。
次に読むなら
更新履歴
- 需要確認
X/Twitterの反応は読者需要の入口としてのみ扱いました。
- 仕様確認
Codex、Claude Code、OpenCodeの公式docsで実行場所と権限を確認しました。
- 記事方針
スマホ操作の便利さではなく、host、承認、MCP、ログの境界へ落としました。
機能や提供条件は変わるため、導入前に各公式docsを再確認してください。
- 2026年6月11日: 初版。Codex Remote Connections、Codex Agent approvals/security、Codex Permissions、Claude Code Remote Control、Claude Code Security、OpenCode Server、OpenCode Permissions、OpenCode MCP serversの公式ドキュメントを確認。X/Twitterの直近反応は需要シグナルに限定し、本文の仕様判断には使っていません。
参照した主な情報源
- OpenAI Developers: Codex Remote connections
https://developers.openai.com/codex/remote-connections
- OpenAI Developers: Agent approvals & security
https://developers.openai.com/codex/agent-approvals-security
- OpenAI Developers: Codex Permissions
https://developers.openai.com/codex/permissions
- Anthropic: Claude Code Remote Control
https://code.claude.com/docs/en/remote-control
- Anthropic: Claude Code Security
https://code.claude.com/docs/en/security
- OpenCode: Server
https://opencode.ai/docs/server/
- OpenCode: Permissions
https://opencode.ai/docs/permissions/
- OpenCode: MCP servers
https://opencode.ai/docs/mcp-servers/