fix: retry LSP/MCP toolsets after tool calls, covering env-wrapped commands (fixes #2457)

[simonferquel-clanker]

Summary

Fixes #2457.

When an LSP or MCP server is configured but not available at session start (binary missing, flag file absent, service not yet running), the agent now retries within the same user turn — after each tool-call batch, without requiring a new user message.

Validated end-to-end with tmux for both MCP and LSP (including the env -C ./backend gopls pattern).

Root causes fixed

MCP — already partially retried, now also covers crashed connections

Toolset.Healthy() returns ts.started. When watchConnection cannot recover the connection it sets ts.started=false, causing StartableToolSet to retry Start() on the next reprobe.

LSP — env -C ./dir gopls was silently swallowed

env always starts successfully (cmd.Start() returns nil), so StartableToolSet.started was set to true even when the inner binary wasn't installed. The new watchExit goroutine is the sole owner of cmd.Wait; it resets h.cmd=nil when the process exits quickly, making Healthy()=false so the next reprobe retries Start().

Changes

File	What changed
pkg/tools/startable.go	HealthChecker interface; StartableToolSet checks health on already-started toolsets; ShouldReportFailure/ConsumeRecovery for deduplication
pkg/tools/builtin/lsp.go	Healthy(), watchExit goroutine (sole cmd.Wait owner, no double-Wait race), exited chan for clean Stop()
pkg/tools/mcp/mcp.go	Healthy()
pkg/runtime/loop.go	reprobe() called after every tool-call batch; compares by name-set diff; updates agentTools in-place
pkg/runtime/event.go + client.go	NoticeEvent / Notice()
pkg/tui/page/chat/runtime_events.go	NoticeEvent → notification.InfoCmd()
pkg/agent/agent.go	Deduplicated warnings; recovery notices

Tests

• pkg/tools/startable_test.go: 6 new tests covering ShouldReportFailure, ConsumeRecovery, HealthChecker integration
• pkg/tools/builtin/lsp_test.go: 4 new tests including TestLSPTool_StartableToolSet_RetriesAfterProcessExits (flag-gated fake LSP, the env -C scenario)
• pkg/agent/agent_test.go: 2 new tests (deduplication, recovery notice)
• pkg/runtime/runtime_test.go: 2 new tests (TestReprobe_NewToolsAvailableAfterToolCall, TestReprobe_NoChangeMeansNoExtraEvents)

tmux e2e results

MCP (gate flag controls server availability):

✓ Shell  touch /tmp/e2e-test/mcp-ready
✓ hello  name=World  Hello, World! MCP is working.
Tools sidebar: 6 tools available  ← was 5

LSP (env -C /tmp/lsp-e2e python3 fake-gopls.py, gate flag controls inner script):

✓ Shell  touch /tmp/lsp-e2e/gopls-ready
✓ Get Workspace Info  (lsp_workspace called natively)
Tools sidebar: 20 tools available  ← was 5

Both in a single user turn, no new user message needed.

[rumpl]

I'm not sure I understand the fix, isn't the lsp tooset startable? Wouldn't re-starting the lsp toolset be enough?

[simonferquel-clanker]

Good question — the LSP toolset is Startable, but there are two separate problems that a naive re-start doesn't cover:

1. env -C ./backend gopls looks like a successful start

When the command is env -C ./backend gopls, exec.Command("env", ...).Start() always returns nil — env is always present. The fact that env then immediately runs gopls, finds it missing, and exits 127 is invisible to cmd.Start(). By the time we return from LSPTool.Start() / startLocked(), h.cmd has been set and the call returned nil, so StartableToolSet sets started = true and considers the toolset live.

A subsequent call to Start() hits the if s.started { return nil } short-circuit and never retries — even though the underlying process died in milliseconds.

2. The HealthChecker interface closes that gap

The fix adds a HealthChecker interface (Healthy() bool) that StartableToolSet checks on every Start() call even when started == true. LSPTool.Healthy() returns h.cmd != nil.

The new watchExit goroutine is the mechanism that transitions h.cmd from non-nil to nil: it is the sole owner of cmd.Wait(), blocks until the process exits, then resets h.cmd = nil. So after env gopls exits 127, Healthy() returns false, StartableToolSet resets started = false, and the next Start() call actually retries — which will succeed once gopls has been installed.

3. The reprobe loop ties it together within a single turn

Even with the above, without the reprobe the agent would only see new tools at the start of the next user turn (when getTools() is called at the top of the run loop). The reprobe() call after each tool-call batch re-runs ensureToolSetsAreStarted immediately, so if a shell tool call installed gopls, the very next model response in the same turn already has the LSP tools in its available-tool list — no new user message needed.