{"version":"2.1.265","anchor":"remoteio-gains-a-stdinlane-constructor-option","canonical_anchor":"remoteio-gains-a-stdinlane-constructor-option","heading":"SDK query() and remote sessions gain a separate stdin lane","tier":"internal","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/remoteio-gains-a-stdinlane-constructor-option","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### SDK query() and remote sessions gain a separate stdin lane\n\nThe SDK's query() and remote\/bridge session IO now support a distinct stdin lane apart from the initial prompt\n\n**Unclear.** What `stdinLane` does and how it affects remote session behavior is not specified in the finding.\n\n**What**\n\nThe class driving a remote (bridge\/cloud) session's stream-json IO now accepts a new `stdinLane` constructor option, alongside the existing `streamUrl`, `initialPrompt`, `sessionState`, and similar options. The SDK's `query()` function, which builds either a local or remote-controlled query stream, now keeps the initial string prompt separate from a raw async-iterable\/generator input, passing the latter through as this new `stdinLane` rather than always coercing all input into a single combined async generator.\n\n**Why**\n\nSeparating the initial prompt from ongoing stdin input lets remote\/bridge sessions handle streamed input more flexibly instead of forcing everything through one merged stream.\n\n- Area: Sessions\n- Names: `stdinLane`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}