{"version":"2.1.271","anchor":"repl-bridge-now-answers-fork-conversation-with-an-explicit","canonical_anchor":"repl-bridge-now-answers-fork-conversation-with-an-explicit","heading":"REPL bridge now answers fork_conversation with an explicit unsupported stub","tier":"internal","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/repl-bridge-now-answers-fork-conversation-with-an-explicit","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### REPL bridge now answers `fork_conversation` with an explicit unsupported stub\n\n`fork_conversation` requests now get a clear 'unsupported' response instead of a generic bridge error\n\n**What**\n\nThe REPL control bridge (used by applications embedding Claude Code) previously returned a generic 'REPL bridge does not handle control_request subtype' error for any request type it didn't recognize, including `fork_conversation`. Now `fork_conversation` is explicitly handled and always returns `{forked: false, error: \"unsupported\", reason: \"requires_remote_control_server\"}`.\n\n**Why**\n\nThis gives embedding applications a clear, specific reason when they attempt to fork a conversation: the feature requires a remote control server, rather than a vague 'not handled' error that doesn't explain why.\n\n- Area: SDK\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}