Extension non-functional on Windows — path encoding bug + likely additional issues

[Whiteaeros]

Environment

• OS: Windows 11
• Claude Code: terminal CLI (Git Bash)
• Extension version: 0.4.7

What happens

Agent Flow panel opens, shows "Live", but always displays zero sessions regardless of active Claude Code sessions. Hooks fire and reach the extension (HTTP POST returns 200), but nothing renders.

Confirmed bug: path encoding broken on Windows

In session-watcher.ts:

this.workspacePath = workspaceFolder.replace(/\//g, '-')

On Windows, uri.fsPath returns a backslash path (e.g. c:\Users\kaleb\Documents\MyProject). The regex only matches forward slashes, so nothing is replaced. The result passed to path.join(CLAUDE_DIR, workspacePath) produces:

C:\Users\kaleb\.claude\projects\c:\Users\kaleb\Documents\MyProject

A colon in the middle of a Windows path is invalid. fs.existsSync() returns false, the directory watcher is never created, and no sessions are ever detected.

Fix:

// Replace backslashes, forward slashes, and colons — matching Claude Code's own encoding
this.workspacePath = workspaceFolder.replace(/[:\/]/g, '-')

This correctly transforms c:\Users\kaleb\Documents\MyProject → c--Users-kaleb-Documents-MyProject, matching the directory Claude Code creates under ~/.claude/projects/.

Likely additional issues

After patching the above locally, the panel still showed zero sessions. The path encoding fix is confirmed correct (it now resolves to the right directory), but something downstream is still failing. Possible candidates:

• The JSONL file watcher or parser may have additional Windows path assumptions
• fs.watch() behavior differences on Windows
• Other replace(/\//g, '-') occurrences elsewhere in the codebase

The extension appears to have been developed and tested on macOS/Linux only. A full Windows pass would likely surface more issues.

[patoles]

Thanks for the detailed report and the clear root cause analysis — that was really helpful.

I've fixed the colon replacement in v0.4.9 (PR #10) — the path encoding now uses replace(/[/\:]/g, '-') as you suggested, so c:\Users\username\project correctly encodes to c--Users-username-project.

That said, there's a known upstream bug in Claude Code itself on Windows (anthropics/claude-code#6578) where the drive letter gets duplicated in the project path. This may still cause issues beyond what we can fix on our end.

If you get a chance to try v0.4.9, I'd love to hear if the other issues you mentioned (JSONL watcher, fs.watch(), etc.) are resolved too. I don't have a Windows environment to verify against at the moment, so any feedback would be appreciated.

[Whiteaeros]

Follow-up: path encoding still broken for paths with spaces (v0.5.0)

The colon fix in v0.4.9 resolved the original issue, but there's a second encoding mismatch: spaces in workspace paths are not replaced.

What happens

In session-watcher.ts, the path encoding regex is:

workspaceFolder.replace(/[/\:]/g, '-')

For a workspace path like c:\Users\username\Documents\My Project Name, this produces:

c--Users-username-Documents-My Project Name

But Claude Code's own encoding also replaces spaces with hyphens:

c--Users-username-Documents-My-Project-Name

The session watcher logs confirm the mismatch:

[SessionWatcher] Starting — scoped to project: c--Users-username-Documents-My Project Name

Since no directory with that name exists under ~/.claude/projects/, the watcher never finds any JSONL files and the panel stays empty. Paths without spaces (e.g. murkml) work fine — this only affects workspace paths containing spaces.

Fix

The regex should also replace spaces (and ideally match whatever Claude Code uses internally):

workspaceFolder.replace(/[/\:\s]/g, '-')

Additional issue: multi-root workspaces

The extension only registers workspaceFolders[0]. In a multi-root workspace with multiple folders, only the first folder gets a discovery file. Sessions running in the second folder are invisible to Agent Flow. The extension should iterate all workspace folders.

Additional issue: triplicated hooks

Each click of "Configure hooks" appends duplicate hook entries to ~/.claude/settings.json rather than checking if hooks already exist. After 3 clicks, every tool call fires the hook 3 times. The configure function should deduplicate or skip if hooks are already present.

Additional issue: stale discovery files on Windows

The hook script's isAlive() function skips PID checks on Windows (if (IS_WIN) return true), so discovery files for dead VS Code instances are never cleaned up. This isn't causing failures (the HTTP POST to a dead port just fails silently), but it's unnecessary overhead. The extension's activation cleanup should handle this, but if the old VS Code window was closed without deactivation, the file persists.