Stale temp files

What mcp-scan saw

The scanner listed os.tmpdir() and /tmp and reported when either holds more than 100 entries. It does not attribute any file to the server being scanned and does not check modification times. This check is gated behind a parameter that the normal scan path leaves off, so it only runs under mcp-scan privacy --retention.

Why it fires

It is a machine-level hygiene signal rather than a server finding: a temp directory that never drains suggests something writes there without cleaning up, and MCP servers that stage files are a common cause. Because it cannot attribute files, it is graded LOW and kept out of the default scan.

When this is a false positive

• The count is machine-wide. On macOS, os.tmpdir() resolves under /var/folders and normally holds well over 100 entries from the OS and from every application you run, with no MCP server involved.
• The check runs once per server, so scanning a config with eight servers reports the same directory eight times.
• There is no age test despite the rule name. A directory with 150 files created in the last minute reports identically to one with 150 files from last year.
• You will only ever see this from mcp-scan privacy --retention, so if it appears in a normal scan report something else emitted it.

How to fix it

1. Look at the temp directory yourself before acting: ls the path and check modification times, which the scanner does not.
2. Attribute the files. If they came from an MCP server, its own cleanup is the fix; if they came from the OS, leave them alone.
3. For a server that stages files, wrap the write in a try/finally that unlinks, or use an OS-managed temp file that is removed on close.
4. Clearing the directory silences the finding without fixing anything, so do it only after you know what wrote the files.
5. Drop the --retention flag if you do not want this check at all. It does not run in the default scan path.