IDE context awareness: stale CLAUDE_CODE_SSE_PORT env var blocks lock file fallback

[Dawnfz-Lenfeng]

Bug

When CLAUDE_CODE_SSE_PORT is set in the environment (e.g. inherited from a VSCode integrated terminal where the Claude Code extension previously ran), opencode will always try to connect to that port and never fall back to lock file discovery at ~/.claude/ide/*.lock — even if that port is no longer reachable.

Root Cause

In packages/opencode/src/cli/cmd/tui/context/editor.ts, resolveEditorConnection() checks the env var first and returns immediately if present:

const port = parsePort(process.env.CLAUDE_CODE_SSE_PORT || process.env.OPENCODE_EDITOR_SSE_PORT)
if (port) {
  return { url: `ws://127.0.0.1:${port}`, source: `env:${port}` }
}
// lock file path is never reached when env var is set
const lock = resolveEditorLockFile(directory)

Since CLAUDE_CODE_SSE_PORT is inherited by child processes, it persists in:

• All terminals opened from the same VSCode window after Claude Code was running
• Any terminal where opencode is launched after a previous session set the variable
• tmux/screen sessions that were started while the variable was set

When the referenced port is dead (VSCode closed, Claude Code extension stopped, etc.), opencode enters a reconnect loop against a dead port with exponential backoff — the lock file mechanism that could correctly find an active IDE connection is completely short-circuited.

Reproduction

1. Open VSCode with the Claude Code extension active
2. Open an integrated terminal — observe CLAUDE_CODE_SSE_PORT is set
3. Close VSCode (the port is now dead)
4. Run opencode in that terminal — it will hang trying to connect to the dead port

Workaround: unset CLAUDE_CODE_SSE_PORT before running opencode.

Suggested Fix

Options (could combine):

1. Health-check on startup: Before committing to the env var path, probe the port (e.g. fetch http://localhost:${port}/app or a WebSocket handshake attempt with short timeout). If unreachable, skip and fall through to lock file discovery.
2. Fallback after repeated failures: If websocket connection via env var fails N times, automatically try lock file discovery instead of continuing to retry the dead port.
3. Re-prioritize: Consider trying lock file discovery first (since it reflects current IDE state) and use the env var only as a fallback, or weigh both candidates and pick the one that's actually reachable.

Related

• PR fix(editor): reject lock files with no workspace match for cwd #24323 fixed a similar cross-directory issue with lock file matching, but the env var priority problem remains.

[github-actions]

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.