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.

[ousamabenyounes]

Thanks for the catch.

Pushed c0e62d6 — tests/providers/claude-symlink.test.ts is now Windows-safe:

• Uses 'junction' symlink type on win32 for directory links.
• Wraps the symlink() call in try/catch; on EPERM / EACCES the test calls ctx.skip(...) with a clear reason instead of failing.
• Real-symlink path still asserts the shady-link directory is dropped on platforms that allow symlinks.

Full suite: 357 / 357. npx tsc --noEmit clean.

[iamtoruk]

Closing this — appreciate the effort, but the threat model doesn't justify the change. codeburn only reads files (no execution, no remote exfil), so symlink following is a non-risk in practice. The PR also only covers one provider while five others have the same pattern. If we decide to add symlink protection later, we'll do it across all providers in one pass. Thanks for the contribution though.