GoLand run cancellation signal mapping to Go code termination

Direct answer

For a local Go run configuration, GoLand does not expose a stable, documented signal mapping. On Unix-like systems the IDE terminates the launched process through the OS process handler—commonly SIGTERM or SIGINT—but the exact signal is not part of a stable public contract and can change across GoLand versions, operating systems, and run versus debug modes. Timeout expiry triggers the same process-termination path as the manual Stop control; the IDE does not send a distinct timeout signal to user code. There is no documented configuration that propagates IDE cancellation directly into a user-supplied context.Context. Stop on close uses the same termination path as the toolbar Stop button: the parent process is terminated, but child processes spawned by your program may be orphaned or survive depending on platform process-group semantics and whether the child detaches from the parent.

Confirmed facts vs. likely behavior

Confirmed: Cancellation happens at the OS process boundary, not inside the Go runtime. Timeout and manual Stop share the same termination mechanism. No IDE setting converts a stop or timeout into context cancellation. Graceful shutdown is the application's responsibility.

Likely but not guaranteed: Unix-like systems often deliver SIGTERM or SIGINT; Windows uses native process-termination APIs rather than POSIX signals. Debug configurations may follow a different termination sequence than plain run configurations. Treat any specific signal number as an implementation detail, not a contract.

What you can rely on

1. Assume your process will be terminated externally, not cancelled through a context.
2. Bridge OS signals to a context yourself. Since Go 1.16, signal.NotifyContext is the idiomatic way:

   ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
   defer stop()
   // use ctx for graceful shutdown

3. If you spawn child processes, explicitly manage process groups or job objects so that terminating the parent also terminates the children. Do not rely on the IDE to clean up detached grandchildren.

Verifying on your setup

Because behavior varies, verify locally. Run a small program that logs received signals via signal.Notify, then press Stop and let a timeout fire. Compare run and debug modes on your target OS. Spawn a detached child (for example, using Setsid on Unix) and check whether it survives after the parent is stopped.

One detail that changes the recommendation

Which operating system and GoLand version are you targeting? On Windows the answer is native termination APIs, not signals, so the bridging strategy differs from Unix. If you are on Unix, the Go version matters too: signal.NotifyContext requires Go 1.16 or newer.