{"version":"2.0.42","anchor":"lsp-request-handler-support","canonical_anchor":"lsp-request-handler-support","heading":"LSP Request Handler Support","tier":null,"area":null,"scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.0.42\/e\/lsp-request-handler-support","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.0.42","markdown":"### LSP Request Handler Support\n\n**What:** LSP servers can now send requests back to Claude Code and receive responses, enabling full bidirectional communication required by the LSP protocol.\n\n**How it works:** The LSP client now supports `onRequest()` to handle incoming requests from language servers, complementing the existing `onNotification()` for one-way messages. This enables proper LSP protocol compliance.\n\n**Details:**\n\n- Added `onRequest()` method to LSP client wrapper at `y$Q() at line 283672`\n- Implemented request handler queueing system (variable `X = []` at line 283555) for handlers registered before connection establishment\n- Exposed `onRequest` in high-level LSP server API at `x$Q() at line 283868`\n- Immediately utilized to handle `workspace\/configuration` requests at line 286293, returning `null` for all configuration items (safe default)\n- **Evidence**: `y$Q() at line 283547-283803` (new LSP client), `x$Q() at line 283893` (exposed API)\n\n**Why it matters:** Many LSP servers (TypeScript, Python, etc.) require clients to respond to `workspace\/configuration` requests during initialization. Without this, some language servers may fail to initialize properly or operate with reduced functionality."}