fix(security): use lstat in claude session discovery to skip symlinks (#153 — gap 2)

[ousamabenyounes]

Summary

Addresses gap #2 of #153 ("Walk functions (providers/claude.ts) don't check for symlinks. Use lstat, skip symbolic links.").

findDesktopProjectDirs and discoverSessions in src/providers/claude.ts walk the session tree with stat, which transparently follows symbolic links. A symlink under ~/.claude/projects/ (or anywhere within the macOS / Linux / Windows Claude Desktop sessions trees) lets the walk descend to any path the calling user can read — outside the intended sandbox.

Fix

Switch the imports from stat → lstat and explicitly skip symbolic links:

const s = await lstat(full).catch(() => null)
if (!s || s.isSymbolicLink() || !s.isDirectory()) continue

Regular directories behave identically; only symlinks are refused. Three call sites in claude.ts:

• top-level walk in findDesktopProjectDirs
• inner projects/* walk in findDesktopProjectDirs
• ~/.claude/projects/ walk in discoverSessions

Verification

• Baseline: 355 pass, 0 fail
• Post-fix: 357 pass, 0 fail (+2 symlink tests, 0 regressions)
• New tests/providers/claude-symlink.test.ts fails on the unfixed code (verified by stashing the fix and re-running — 'shady-link' was discovered)
• npx tsc --noEmit clean
• No bracket-assign on {}-init maps in src/parser.ts or src/providers/ (semgrep guard)

Out of scope

Gap #1 of #153 (ANSI sanitization of displayed strings) is the companion PR.

The same stat-vs-lstat pattern exists in other providers (pi, codex, copilot). Per the issue text the symptom was reported in providers/claude.ts, and a single-provider PR is easier to review than a sweep. Happy to follow up across the other providers in a separate PR if you'd like.

Files changed

File	Change
src/providers/claude.ts	stat → lstat; explicit symlink skip at 3 call sites
tests/providers/claude-symlink.test.ts	new — symlink dropped, regular dir kept

---

Vibe Coded by Ousama Ben Younes
Developed With Ora Studio (Claude Code)

[Qodo-Free-For-OSS]

Hi, The new symlink test creates a directory symlink without Windows-safe options or error handling, which can fail on win32 (often EPERM/EACCES) and break CI/dev runs on Windows.

Severity: action required | Category: reliability

How to fix: Make symlink creation Windows-safe

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

tests/providers/claude-symlink.test.ts creates a directory symlink in a way that is likely to fail on Windows.

Issue Context

On win32, fs.promises.symlink() frequently requires admin privileges and/or an explicit link type; otherwise it throws (EPERM/EACCES), making the test suite fail on Windows.

Fix Focus Areas

• tests/providers/claude-symlink.test.ts[37-41]

Potential approaches:

• Use await symlink(realTarget, linkPath, 'dir') on Windows/macOS/Linux.
• Or on Windows prefer junction (symlink(target, path, 'junction')) for directory links.
• If symlinks are not permitted in the environment, skip the test with a clear reason when symlink() fails with EPERM/EACCES.

We noticed a couple of other issues in this PR as well - happy to share if helpful.

---

Found by Qodo. Free code review for open-source maintainers.