
修正が終わったなら、セッションを閉じてよいか知りたい。それだけの確認で、Codexの説明が完了・未完了・対応不要の間を何度も行き来しました。手元の作業手順を変えたことと、それでも残った問題をIssueで報告したことを、分けて振り返ります。

many-ai-cliの黄色の停止表示を直してもらったあと、残作業を確認しました。「あなたの操作は不要」「閉じて大丈夫」と言われた一方で、一時フォルダの削除が拒否された話や、別セッションへの影響が未確認という話が残っていました。
聞き直すと、追加作業は不要という説明が撤回され、別作業の状態を確認すべきだと説明されました。その後また不要と言われ、片付けを問うと再び撤回されました。最新の返事だけでは、誰が何をする必要があるのか判断できませんでした。
この終了確認の前にも対応しています。バグ修正が長引いた時点で作業を止め、図付きの経緯説明を求めました。親セッションが修正を引き取り、子の広い変更候補をそのまま採用せず、元の不具合の範囲に戻しています。
再発防止の実装も承認しました。調査段階と実装準備済みを区別し、依頼文書の不足や方針の版違いを判別する検査道具を追加しました。既存の委託skillとbugfixルールを更新し、親は委託前、子は編集前に同じ文書を検査する手順へ接続しました。同じ論点で2回目の差し戻しになったら、親が指示・差分・証拠を見直す手順も入れています。
道具の合成ケース89件と別CLI受入31件は通りました。ただし、確かめたのは入力の不足や不一致を判別する働きです。AIの説明が矛盾しなくなった、という検証ではありません。
手元の対策が対象にするのは、実装前の引き渡しです。終了説明の反転までは自動検査しません。そこで、実際の発言と説明が変わった順序をまとめ、認証済みのGitHub CLIからOpenAIへIssueを1件送りました。
送信したIssue #54939は、2026年10月18日7時15分ごろに投稿され、投稿者と本文の一致を確認しています。投稿できたことと、OpenAIが調査・回答・修正したことは別で、後者まで進んだとは確認していません。別セッションが終了した原因も未確定です。
次に試す案は、目的の達成を示す証拠、未完了の作業、原因未確定の事項、次の操作と担当、判断を変えた根拠を固定の項目で報告してもらうことです。削除できないなら未削除、原因が分からないなら原因未確定。その状態を、聞き返されたというだけで対応不要へ変えないよう求めます。
この形式で今回の問題を防げた実績はなく、専用の自動検査も未実装です。手元で変更した工程と、これから試す方法を一緒に「対策済み」とは呼ばないようにします。

実際の会話の引用、問い直した内容、導入した道具の確認範囲はQiitaの全文にまとめています。