forge-lsp exits with SIGKILL immediately on LSP server startup

[MelbourneDeveloper]

Symptom

The VS Code extension fails to connect to forge-lsp immediately after activation with these errors in sequence:

Server process exited with signal SIGKILL.
Server initialization failed.
  Message: Pending response rejected since connection got disposed
  Code: -32097
Forge client: couldn't create connection to server.
  Message: Pending response rejected since connection got disposed
  Code: -32097

The extension log shows all activation steps complete normally up to client.start, then the process is killed:

[2026-04-27T03:14:44.048Z] step 11: client.start (await)
[2026-04-27T03:14:44.048Z] Server binary: forge-lsp
[Error - 13:14:44] Server process exited with signal SIGKILL.

What is known

• The forge-lsp binary exists, is arm64, has correct permissions (-rwxr-xr-x), and has no quarantine extended attribute
• Running forge-lsp --version from the terminal works fine
• The binary was freshly installed via make install-rust moments before the failure
• This is not caused by the slnx branch — the connection/startup code path is unchanged from main

Likely causes (to investigate)

1. macOS memory pressure / jetsam kill: macOS can SIGKILL a process instantly at launch if memory is critically low. The kill happens before any stdout/stderr is produced.
2. Gatekeeper/notarization: macOS may kill unsigned binaries silently on first run in some security configurations (though no quarantine xattr was observed).
3. Crash on startup before LSP handshake: forge-lsp may panic or abort in the first milliseconds of startup (e.g., during sidecar discovery or tokio runtime init). The SIGKILL label from VSCode's language client may misreport SIGABRT or exit code 134 as SIGKILL.
4. Race with the install: the binary was being written by make install-rust at the exact moment VSCode tried to launch it.

Reproduction steps

Not consistently reproducible — appears intermittent. Observed once immediately after make install-rust ran during CI prep.

Expected behaviour

forge-lsp starts, completes LSP initialize handshake, and the extension connects.

Environment

• macOS Darwin 25.3.0 arm64
• VS Code with Forge extension
• forge-lsp built from slnxsupport branch (commit ad95574)

[MelbourneDeveloper]

Root cause identified and fixed in commit 7ed9b23.

The 'SIGKILL' in the VSCode output is the default vscode-languageclient error handler labelling any unexpected server close as a kill. The actual cause is transient: VS Code kills the old forge-lsp process when restarting the extension host (e.g. after make install-rust replaces the binary on disk during development), then immediately tries to start a new one. The default handler shows a modal error on every such close, making it look like a hard failure.

Fixed by replacing the default error handler with a custom one that:

• Silently restarts up to 5 times (handled: true suppresses the modal)
• Shows one actionable 'Show Output' message only after 5 consecutive failures
• Resets on recovery so normal sessions aren't affected

[abdushakoor12]

The root-cause fix (custom makeErrorHandler in editors/vscode/src/client.ts — returns CloseAction.Restart with handled: true for up to 5 unexpected closes, then one actionable Show Output message) is present in this repo. It landed here as commit 46e76c3 (PR #7); the 7ed9b23 hash in the earlier comment is from the pre-rename forge-lsp/Forge repo, and the fix was ported over.

It had shipped without a regression test, so I've added a coarse e2e guard (6a8552e): it SIGKILLs the exact staged sharplsp server binary out from under the live client — reproducing the #8 scenario — and asserts the client auto-recovers and serves document symbols again without any restartServer command. Verified passing (server auto-recovers in ~50ms after the kill).

Autocloses on merge via Closes #8.