What causes "Failed to initialize LSP: no response" in can1357/oh-my-pi?

Verify the configured command actually starts a language server (run it manually)

Failed to initialize LSP: no response

Error message

Failed to initialize LSP: no response

What it means

During client startup the library sends the LSP `initialize` request with a timeout. If the request resolves to nothing (null/undefined result) rather than a capabilities object, the client cannot proceed and throws this error — the server never answered the handshake.

Source

Thrown at packages/coding-agent/src/lsp/client.ts:1102

		try {
			// Send initialize request
			const initResult = (await sendRequest(
				client,
				"initialize",
				{
					processId: process.pid,
					rootUri: fileToUri(cwd),
					rootPath: cwd,
					capabilities: CLIENT_CAPABILITIES,
					initializationOptions: config.initOptions ?? {},
					workspaceFolders: currentWorkspaceFolders(client),
				},
				signal,
				initTimeoutMs,
			)) as { capabilities?: unknown };

			if (!initResult) {
				throw new Error("Failed to initialize LSP: no response");
			}

			client.serverCapabilities = initResult.capabilities as LspClient["serverCapabilities"];

			// Finish the initialize handshake before publishing the client as ready.
			await sendNotification(client, "initialized", {}, signal);
			await sendNotification(
				client,
				"workspace/didChangeConfiguration",
				{ settings: config.settings ?? {} },
				signal,
			);

			client.status = "ready";
			// Publish only after init succeeds: pre-init clients are reachable
			// solely through clientLocks, so concurrent callers (warmup vs first
			// tool call) wait for init instead of using an unacknowledged client.
			if (invalidatedClientKeys.has(key)) {

View on GitHub (pinned to 9690622007)

Solutions

Verify the configured command actually starts a language server (run it manually)
Check server stderr/logs for crash output during initialization
Increase initTimeoutMs if the server is slow but functional
Update or reinstall the language server binary

Example fix

// before
command: "typescript-language-server"
// after
command: "typescript-language-server", args: ["--stdio"]

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: confirm the command starts and stays alive
const proc = Bun.spawn([config.command, ...config.args], { stderr: 'pipe' });
await Bun.sleep(500);
if (proc.exitCode !== null) throw new Error(`LSP server exited immediately: ${await new Response(proc.stderr).text()}`);
proc.kill();

Try / catch

try {
  const client = await getConfigOrCreate(config, cwd);
} catch (err) {
  if (err.message === 'Failed to initialize LSP: no response') {
    logger.error('LSP server did not answer initialize', { command: config.command });
    // check server logs / reinstall server
  }
  throw err;
}

Prevention

Manually run the configured command with --stdio to confirm it is a real language server
Match server args to the expected transport (e.g. --stdio)
Keep the language server updated; old protocol versions may fail the handshake
Raise initTimeoutMs for slow-starting servers

When it happens

Trigger: The initialize request completed its await without producing an initResult: server closed the connection, the framed response never arrived, or the transport returned an empty result before initTimeoutMs elapsed.

Common situations: Server binary is a CLI wrapper that exits immediately; wrong command args so the process isn't a language server; server speaks a different protocol version; server killed by OOM during startup.

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/25cc88692ad47703. Report an issue: GitHub.