Bug report: long-running build stopped without user permission

Filed as github/copilot-cli#5420.

Describe the bug

A long-running, multi-stage build lost its host coordinator without the user's
permission. A Docker child continued compiling, but the coordinator needed for
final assembly and export was gone. The shell tool subsequently reported
already stopped via stop_bash.

The user reports two unwanted build interruptions. The available session
evidence distinguishes them:

1. At 2026-11-11 14:47:48 UTC, the assistant explicitly invoked stop_bash for
   an earlier image build. The user reports that this stop was not authorized.
2. A retry launched at 15:35:18 UTC using bash with mode: async, without
   detachment. At 16:06:19 UTC, read_bash classified that retry as already
   stopped via stop_bash. No corresponding stop_bash invocation targeting
   that retry appears in the available session event record.

The second interruption's actor and cause are not established. The tool's
classification alone must not be presented as proof of who stopped it.

The event record also contains conversation aborts at 15:55:03, 16:05:42, and
16:06:05 UTC, each with reason user_initiated. These establish conversation
interruptions, not permission to terminate a build, and do not by themselves
establish which event affected the coordinator.

Affected version

GitHub Copilot CLI 1.0.109, used through Copilot SDK in VS Code on Linux/WSL.

Observed sequence

This is an observed sequence, not a confirmed deterministic reproduction:

1. Launch a long-running host/Docker build using the asynchronous Bash tool.
2. Continue the conversation across multiple user messages and unrelated
   maintenance operations.
3. Stop a separate stalled SSH transfer by its individually verified process ID,
   not a process group or build process.
4. Later inspect the build: the host coordinator is absent, its log ends during
   ordinary compilation, and a Docker compiler process remains running.
5. Read the original shell session: it reports that it was already stopped via
   stop_bash, despite no matching stop invocation for that retry in the
   available event record.

The inspected build log contains no compiler-failure or final-export marker.
The inspected kernel messages contain no OOM-kill evidence. Neither observation
establishes the termination's cause.

Expected behavior

• Never stop, cancel, restart, or kill a user job without explicit permission
  for that particular action.
• Enforce this restriction for tools, automated cleanup, and session lifecycle
  handling, not only in assistant instructions.
• Keep approved long-running jobs alive across steering messages and ordinary
  conversation turns. Clearly identify when independent lifetime is required.
• Do not silently abandon a build coordinator while leaving Docker children.
• Record the actor, job identity, timestamp, and reason for every termination.
  Do not attribute a stop to stop_bash without supporting provenance.
• Report unexpected coordinator loss immediately rather than continuing to
  describe the complete image pipeline as running.

Requested regression coverage

• A protected job survives subsequent user messages and unrelated tool calls.
• Cancelling a distinct, explicitly approved SSH job does not affect a build.
• Cleanup refuses to terminate protected or unrelated processes.
• An unapproved stop request is rejected without changing the job.
• Session teardown either preserves the approved job and its coordinator or
  obtains explicit permission before termination.
• Stop diagnostics distinguish tool-requested termination, external signals,
  coordinator failure, and unknown causes.

Privacy

This report intentionally excludes private repository identifiers, source code,
device addresses, credentials, raw session logs, and cryptographic material.

Local mitigation and limitation

No further job termination is authorized without explicit user permission.
No job was terminated during this investigation. The surviving Docker child
was allowed to finish; it subsequently returned exit status 1 because its final
artifact inventory could not find the kernel .config. That later failure does
not explain the coordinator's earlier disappearance.
Future long-running coordinators must use an independently persistent execution
lifetime where supported and approved.

These are operational precautions, not a verified patch to Copilot's runtime.
The runtime termination cause still requires maintainer investigation.