fix: path traversal vulnerability in listDirectory (#463)

[Jah-yee]

Summary

• Fixes security vulnerability reported in issue Bug: list-directory path traversal — missing path.sep in startsWith check #463
• Path traversal check can be bypassed with sibling directories sharing a prefix

Root Cause

The original check !resolvedPath.startsWith(projectPath) fails when:

• projectPath = /home/user/project
• directoryPath = ../project-evil
• resolvedPath = /home/user/project-evil
• /home/user/project-evil.startsWith(/home/user/project) = true (incorrectly allows)

Fix

if (
  !resolvedPath.startsWith(projectPath + path.sep) &&
  resolvedPath !== projectPath
) {

This matches the pattern already used in code-search.ts (lines 52-53).

Testing

The fix ensures:

1. Direct child directories are accessible (e.g., src, ../sibling)
2. Parent directories are blocked (e.g., .., ../../etc)
3. Sibling directories with shared prefix are blocked (e.g., ../project-evil)
4. Project root itself can be listed

[hiSandog]

I think this fixes the shared-prefix case, but sdk/src/tools/list-directory.ts still looks traversable through symlinks inside the repo.

path.resolve(projectPath, directoryPath) only normalizes the lexical path. If the workspace contains something like project/link -> /etc, then directoryPath="link" resolves to /repo/link, passes the new startsWith(projectPath + path.sep) guard, and fs.readdir(resolvedPath) will still enumerate /etc.

So the old prefix bug is closed, but an attacker can still escape the project root through a checked-in or generated symlink. I would either compare realpath(projectPath) vs realpath(resolvedPath) before reading, or explicitly lstat and reject symlinked directory targets.