Windows IDE connection cannot recover from stale terminal port metadata

[acoliver]

Summary

On Windows, /ide enable cannot recover when an existing VS Code integrated terminal contains stale LLXPRT_CODE_IDE_* metadata after the companion server restarts. The CLI is designed to refresh connection metadata from the companion port file, but getIdeProcessInfoForWindows() can identify the integrated terminal shell as the IDE process. It therefore searches for a port file under the wrong PID and falls back to the dead environment port.

Environment

• Windows 11
• VS Code 1.129.1
• Locally built and installed LLxprt Code IDE Companion 0.10.0
• LLxprt launched from the repository with bun scripts/start.ts --profile-load gpt56high
• Workspace: the llxprt-code repository

Reproduction

1. Open the repository in VS Code with the LLxprt Code IDE Companion installed.
2. Open an integrated PowerShell terminal while the companion server is using one port.
3. Restart/reload the companion extension so it creates a new server port and port file.
4. From the already-open terminal, launch LLxprt Code.
5. Run /ide enable, then /ide status.

Actual behavior

/ide status remains disconnected.

Observed in the failing LLxprt process, with the auth token value deliberately not printed:

• TERM_PROGRAM=vscode
• LLXPRT_CODE_IDE_SERVER_PORT=49975
• workspace variable present and correct
• auth-token variable present
• no listener or port file exists for port 49975
• live companion port file: llxprt-ide-server-29396-64365.json
• live listener: 127.0.0.1:64365

A direct IdeClient diagnostic connects successfully when supplied the live port-file metadata, proving the companion server is healthy.

The live process chain was:

bun CLI (15604)
  -> bun scripts/start.ts (23676)
  -> pwsh integrated terminal (29180)
  -> Code utility / extension host (26336)
  -> Code main process (29396)

The current Windows heuristic in packages/ide-integration/src/ide/process-utils.ts selects the great-grandchild of the root (ancestors[ancestors.length - 3]). For this valid VS Code process tree it returns PID 29180 (pwsh.exe), not PID 29396 (Code.exe). getConnectionConfigFromFile() consequently searches for:

llxprt-ide-server-29180-*.json

No such file exists. It then falls back to stale environment port 49975, where no server is listening.

Expected behavior

/ide enable should rediscover the currently running companion and connect even when the integrated terminal inherited stale server metadata.

Suggested direction

Make Windows IDE-process discovery identify the actual IDE ancestor rather than relying on a fixed ancestor offset. Candidate signals include executable/command matching for supported IDEs and validating candidate PIDs against current companion port files. Recovery should remain scoped to the current IDE/workspace and preserve auth-token validation; it should not connect to an arbitrary port file.

Add a Windows-focused behavioral test with a process tree containing CLI -> wrapper -> shell -> Code utility -> Code main, plus a stale environment port and a live port file keyed to the Code main PID.

[coderabbitai]

🔗 Related PRs

#704 - Fix VSCode companion activation by bundling tiktoken wasm (#692) [merged]
#1410 - fix(cli): harden terminal protocol restoration on exit paths [merged]
#2100 - Remove package ESLint suppressions (Fixes #2089) [merged]
#2610 - Launch installed CLI directly with bundled Bun (Fixes #2603) [merged]
#2632 - Prevent OAuth browser launch from hiding Windows terminals [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!