GitHub接続を最初から外部実行へ分離する

.agents/skills/github-external-operations/SKILL.mdを追加し、GitHub remote、API、gh、app connectorによるread / writeを、最初からsandbox-external contextまたはsandbox内DNSに依存しないconnectorで実行する契約を定めた。domain allowlistは互換設定であり、sandbox内接続の可用性や許可を保証しないものとして、接続probeと失敗後の再試行を禁止した。

• 最初にworkspace root、origin、親子境界、local状態をread-onlyで確認し、GitHub上の状態はconnectorを第一候補として取得する。
• connectorが利用不能、権限不足、対象workspaceや作業対象を特定不能、または必要な操作を提供しない場合に限り、通常の外部操作をsandbox-externalのCLIへ切り替える。
• remote Gitまたはghを使う前に、対象workspace自身の認証helperを同じ外部実行contextで動かし、子workspaceから親helperを流用しない。
• 外部状態を書き換えた後は状態を再取得し、対象と結果が一致するまで完了と報告しない。

connectorとsandbox-external contextの両方が使えない場合は、environment blockerを返すようにした。blockerには対象workspaceと予定操作、使えない経路と理由、未変更または未確認の外部状態、localだけで完了した範囲、満たせないgate、next actionと返却先を含める。copy-readyな文面は未作成draftとして返せても、外部状態を作成・確認した証拠や必須gateの代わりにはしない。

認証失敗時だけ再認証へ進み、secretやcredentialを出力しないこと、workspaceごとのhelper境界を保つこと、高risk操作の承認を外部実行という理由で緩めないことをinvariantにした。外部実行は操作場所の指定であり、権限を追加する仕組みではない。

最初の実装確認では、共有SkillがCLIへのfallbackを「connectorに必要な操作がない場合」だけに絞る一方、一部の役割定義とsetup文書は利用不能、権限不足、対象特定不能も条件に含めていた。この不一致を修正し、通常操作の四条件、高riskな状態変更のno-fallback、外部実行、認証preflightを同じ表現へそろえた。

新しいSkillを既存のdelivery Skillと変更確認Skillから必須参照し、9件のcustom role、実行config、command rules、運用chart、setup、handoff例へ同じ境界を反映した。新しいroleは追加せず、最大同時thread数と階層の設定も変更しなかった。

確認方法として、3件のrepo-local Skillをvalidatorへ通し、Skill用YAMLとconfig・9件のrole TOMLをparseした。さらに、9件すべてが新しいSkillへroutingされていること、fallbackとenvironment blockerの語彙が横断一致すること、command policyの代表ケース、placeholder、差分の空白を検査した。

- GitHub app / plugin connectorはsandbox内DNSに依存しないsandbox-external pathとして第一候補にする
- CLIが必要な時はcommandを最初からsandbox-external execution contextで実行する。sandbox内で接続可否をprobeせず、DNS / egress failure後の再試行経路にしない
- `.codex/config.toml`のGitHub domain allowlistは他用途との互換設定であり、sandbox内GitHub操作の可用性、許可、fallbackを保証しない