[Dots/Stop controls] An operation to stop related chats, Goals, and scheduled runs in bulk within a specified scope and read back their actual stop states #52209

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   dotsIssues involving setting up ChatGPT dots or managing their ongoing work.Issues involving setting up ChatGPT dots or managing their ongoing work.

   automations

   on Oct 8, 2026
2. github-actions

   changed the title [-][Dots/停止制御] 関連チャット・Goal・定期実行を範囲指定で一括停止し、実停止を読戻す操作[/-] [+][Dots/Stop controls] An operation to stop related chats, Goals, and scheduled runs in bulk within a specified scope and read back their actual stop states[/+] on Oct 8, 2026
3. github-actions commented on Oct 8, 2026

   

   github-actionsBot

   on Oct 8, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation:

   Feature request

   When using Dots as a central interface to run multiple Codex chats, ongoing Goals, and scheduled runs, an operation is needed to stop everything that the interface started or manages in bulk and verify that each target has actually stopped.

   The official Dots controls documentation explains that Pause stops the current main task and does not stop all delegated work or future scheduled runs. I am not claiming this is a bug that violates that specification. This is a request for an improvement that lets users “stop all the work I asked this interface to do” without relying on multiple individual stop operations and natural-language replies.

   What actually happened (anonymized)

   Conversation records from 2026-10-09, Japan time:

   Time	Recorded state
   02:05:36	The user requested that all related work be stopped
   02:07:22	The coordinator reported that some stop instructions had been canceled and that a complete stop had not been confirmed
   02:13:21	The coordinator reported that it could not use an operation to directly force a stop and that the complete stop was unfinished
   02:16:31	The coordinator reported that stop instructions had been accepted for 9 workers and that 2 of them had replied that they had stopped. The other workers and the formal Goal remained unconfirmed
   02:20:49	The user reported having stopped the work themselves
   02:20:58	The coordinator corrected its explanation that had implied it had been able to stop the work itself

   The interval from the initial request to the user's report of intervention was 15 minutes and 13 seconds. This is not the time it took for execution to actually stop, nor is it proof that all work continued throughout that interval. The problem is that the user could not verify the stop states and had to take over managing multiple executions themselves.

   Requested operation

   1. Display the scope of related tasks started or managed by this interface, chats explicitly added to its management scope, Goals, and scheduled runs.
   2. Prevent new starts and restarts within that scope, then stop running turns.
   3. Pause the target Goals and disable the target scheduled runs. Do not affect unrelated user work.
   4. Independently read back request accepted, turn stopped/idle, goal paused, schedule disabled, unreachable, and failed for each target.
   5. If only some targets have stopped, do not treat the operation as complete. Display the unconfirmed targets and the actions the user can take.

   Management permissions, target associations, and the stop scope need to be explicit, and natural-language declarations that work has stopped must not serve as evidence of a state change.

   Proposed synthetic regression test (not run)

   Start 2 regular chats, 1 ongoing Goal, and 1 scheduled run from a single interface. Make one of them temporarily unreachable, then perform a scoped stop. Verify that stopped targets and unconfirmed targets are distinguished, that the target scheduled run does not start new turns after the stop, and that chats outside the scope continue running.

   Related issues and environment

   #38237 and #42032 primarily report subagent proliferation and child execution after the parent has ended. The scope here includes not only descendants of collaboration.spawn_agent, but also a management scope spanning independent Codex chats, Goals, and scheduled runs. Please link these issues if they can be integrated under a common execution lifecycle.

   Mac at the time of reporting: macOS 26.3 / Apple Silicon, Codex 26.1002.52244, build 13536. The versions of the individual cloud execution environments at the time of the incident have not been confirmed. I have not measured usage allowance consumption or financial losses and make no claims about them. The public issue body does not include the original conversation text, private IDs, or business details.