Skip to content

guardrails: nothing catches a POSIX /tmp path resolving to a Windows drive-root C:\tmp #2594

Description

@kyle-sexton

Problem

On Windows, a hardcoded POSIX /tmp path resolves to C:\tmp on the current drive rather than to the platform temp directory (%TEMP%C:\Users\<user>\AppData\Local\Temp). Nothing catches this, so it accumulates silently at the volume root.

Evidence

A disk-hygiene audit of C:\ found 4,802.9 MB across 34,416 files in 16 directories under C:\tmp, accumulated over roughly a month without notice.

Attribution is confident and it is not Claude Code: every checkout sits on a codex/* branch, the four tmp.XXXXXXXX entries are mktemp-shaped, and one directory holds a scraped Codex manual. This is OpenAI Codex session residue.

That external origin is the point — we cannot fix the writer, but we can notice it. The residue was durable (every commit confirmed present on GitHub, every stash duplicated in the real checkout under the ghq root), so nothing was lost. It simply sat there, invisible, growing.

Proposed change

A guard that detects a write target of /tmp, C:\tmp, or any drive-root \tmp on Windows and either redirects it to the platform temp directory or surfaces it, so this cannot silently accumulate again.

Open design question worth deciding before implementing: redirect (silent, safe, but hides a real bug in whatever tool is doing it) versus warn (visible, actionable, but noisy if the tool is not ours to fix). Given the writer here is external, warning may be the more honest behavior.

Related

A sibling issue covers claude-code-proxy's own drive-root residue, which has a different cause — deliberate MAX_PATH testing whose teardown does not survive a failed run.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions