Validate session and task ids to close a path traversal

[dgruhin-hrizn]

Security: path traversal on an unauthenticated API

Express URL-decodes route params, so %2f inside :sessionId becomes a real path separator after decoding and path.join(TASKS_DIR, sessionId, …) walks straight out of the tasks tree. No route validates either param.

Demonstrated against a throwaway CLAUDE_DIR, with a canary at <CLAUDE_DIR>/projects/victim/secret.json:

DELETE /api/tasks/..%2fprojects%2fvictim/secret
  → HTTP 200, canary deleted

The route appends .json, so the primitive is limited to files with that extension — which still covers package.json, tsconfig.json, and any *.json holding credentials.

Why this is more than a local-only bug

• app.listen(port) binds 0.0.0.0, not loopback, so the API is reachable from anything on the same network. That's a real configuration in practice — the viewer is genuinely useful from a phone on the same wifi.
• No auth, no CORS config, no origin check. A LAN client needs nothing but curl.

Being precise about the threat model, since it affects how urgent this is: a drive-by from a random web page is mostly blocked, because a cross-origin DELETE isn't a CORS-simple request and Express answers no preflight. The realistic vectors are direct LAN access, and chaining from same-origin script execution (see #27, and PR #25).

The fix

Adds SAFE_ID (/^[A-Za-z0-9._-]{1,128}$/, with . and .. rejected explicitly) and guards the three routes that take these params, returning 400. Also skips task objects whose on-disk id fails the same check, so malformed files never reach the client.

Purely additive — no existing line moves. 36 insertions, 0 deletions.

Verification

	unpatched	patched
DELETE ..%2fprojects%2fvictim/secret	200, file deleted	400, file intact
GET /api/sessions/..%2f..%2fprojects	200	400
GET /api/sessions/<real-id>	200	200 (unchanged)

One thing worth considering separately: binding to 127.0.0.1 by default with an opt-in --host flag would defend this in depth. I've deliberately not done that here, because it would break the phone-on-LAN use case that I suspect a number of people rely on — it deserves its own PR and its own discussion rather than being smuggled into a security fix.