{"version":"2.1.271","anchor":"bridge-child-process-kill-is-now-correctly-classified-as-in","canonical_anchor":"bridge-child-process-kill-is-now-correctly-classified-as-in","heading":"Bridge child process kill is now correctly classified as \"interrupted\" even on nonzero exit","tier":"notice","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/bridge-child-process-kill-is-now-correctly-classified-as-in","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### Bridge child process kill is now correctly classified as \"interrupted\" even on nonzero exit\n\nDeliberately killed bridge child processes are now correctly logged as interrupted, not failed\n\n**What**\n\nWhen Claude Code deliberately kills a spawned bridge or fleet session's child process, it now sets a flag before sending the termination signal. The exit handler checks that flag, along with a nonzero exit code, to correctly classify the outcome as \"interrupted\" rather than \"failed.\" The debug log line for spawning a child process now also reports auto-mode settings and fact count.\n\n**Why**\n\nThis fixes cases where an intentional shutdown of a child process was being misreported as a failure, making logs and status reporting more accurate.\n\n- Area: Remote Control\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}