(mcp): IDE emulation reports itself working when it is not

[jbr-sekoia]

Two places report IDE emulation as working when it is not, and neither can surface the failure. They are the same shape as the defect #316 fixes, and as the missing terminal link provider being built alongside it: a state that reads right and is not.

1. mcpActive means "a server is listening", not "the CLI connected"

main.js:2299 (reattach) and main.js:2630 (spawn) both set it from the presence of the server object. The "IDE Emulation" badge in the terminal header is driven by it (public/file-panel.js:574-581, rendered at :1489-1508).

The proof that IDE emulation actually works is the wss.on('connection') handler in mcp-bridge.js firing — the CLI attaching to the websocket. A session where the server started and the CLI never attached shows the badge and behaves exactly as if the feature were off.

Failure scenario. The lockfile is written, the port listens, the CLI is spawned without ever connecting (a --ide that did not take, a CLI version that does not discover the lockfile, a port already claimed by a stale peer). The badge says IDE Emulation. Every file open goes nowhere, and nothing in the UI distinguishes this from a healthy session.

2. The spawn-time catch degrades silently

// main.js:2537-2545
if (sessionOptions?.mcpEmulation !== false) {
  try {
    mcpServer = await startMcpServer(sessionId, [spawnCwd], mainWindow, log);
    claudeCmd += ' --ide';
  } catch (err) {
    log.error(`[mcp] Failed to start MCP server for ${sessionId}: ${err.message}`);
  }
}

A session that could not register starts anyway, without --ide, and is indistinguishable from one that did except in the log. The badge is correctly off here — mcpServer stays undefined — but nothing says why, so the user sees a feature that is on in settings and absent in the session, with no route to the cause.

Scope, so the three do not overlap

• (settings): two tables of defaults disagree, so IDE Emulation reads on and behaves off #316 covers the defaults drift between SETTING_DEFAULTS and the settings panel's own fallbacks, which is what made the feature off while the toggle showed on.
• The terminal link provider covers paths in the scrollback not being clickable.
• This issue covers the two reporting defects above. Neither would have caught (settings): two tables of defaults disagree, so IDE Emulation reads on and behaves off #316's defect — nothing failed there, the branch was simply skipped — which is the argument for fixing what is silent and not only what is visible.

Three instances of one failure mode in one subsystem argues for a rule rather than three patches: a state indicator reports the thing it claims to report, or it is not shown. Worth settling in this issue rather than separately in each fix.

Evidence

Measured on this machine, 2026-09-22. ~/.claude/ide/ empty across sessions while Global Settings showed IDE Emulation ticked; zero [mcp] lines in the app log, establishing that startMcpServer was never called rather than having failed; after saving the settings dialog once, ~/.claude/ide/40141.lock appears and the badge shows for a new session.

Separately measured, and the reason the terminal route matters at all: an agent cannot put a file in the side panel itself. openFile and openDiff are declared by the bridge (mcp-bridge.js:52-80) but the CLI exposes only getDiagnostics to it, and an OSC 8 hyperlink cannot be emitted from a tool call — its stdout is a file, and /dev/tty cannot be opened from it.

[jbr-sekoia]

Accepted, with the rule stated one step more generally — as written it covers two of the three instances and not the one that started this.

"A state indicator reports the thing it claims to report, or it is not shown" fits the badge and it fits a link. It does not fit the settings toggle, because a toggle is not an indicator: it is a control, and the defect was that its displayed value was not the value in force. Not showing it would have been no improvement.

What covers all three: what the interface displays is what is in force. For an indicator, the state that actually holds. For a control, the value a new session will actually get. For an affordance, whether acting on it will work.

The three instances then read as one rule broken three ways:

• the toggle displayed a value no session would receive ((settings): two tables of defaults disagree, so IDE Emulation reads on and behaves off #316);
• the badge displays a listening socket while claiming a working IDE (here);
• a link would display an affordance that does nothing, if it were offered for a path the panel refuses — which is why the provider links only what it has established is openable, rather than linking on shape and refusing on click.

The second option is worth keeping in view for the badge specifically. "Or it is not shown" is one way out; the other is to show what is actually known. A session whose server is listening but whose CLI never attached is a real state, distinct from both "working" and "off", and saying so is more useful to someone debugging than showing nothing. That is a design call for whoever takes this, not a requirement — but "report less" and "report accurately" are not the same thing, and only the second is the rule.

On the silent catch: the argument that it is worth fixing even though it would not have caught #316 is right, and it is the stronger half of this issue. A session that could not register is a state the app knows and does not say. The log is not a route for the person using the app.

The scope split is right and I am not changing it. The link provider's rule — only an openable path is linked — is being written into .ai/contexts/terminal-path-links.md as a property of that mechanism, so it does not depend on this issue landing.