A developer says Cursor's agents kept parking work in /tmp, and macOS wiped 16 hours of it

This is one person's account on Cursor's community forum, not independently confirmed. A Cursor staff member replied to it, and that reply is described below.

What happened

The developer is a heavy Cursor user on macOS 15, running long agent chats on a large git repository with a live local checkout they couldn't disturb. To avoid switching branches on top of that live folder, the agents kept creating separate git worktrees under /tmp. The developer says it happened across many chats over a week, and that subagents also picked /tmp as the safe place.

Cursor then bound the conversation to that /tmp path, so from then on the agent's workspace was a temporary folder. On a Mac, /tmp is cleared on reboot and by periodic clean-up. When macOS wiped it, the developer says they lost about 16 hours of work in one go.

Why nobody noticed

According to the report, nothing in the interface showed that the chat lived in /tmp. The window, chat title and file tree looked like a normal project. After the wipe the file tree was simply empty and the chat still looked fine. The developer only found out by asking the agent. Even after they added a user rule and a hook forbidding /tmp, they say agents kept using it, because the chat's own workspace was already there.

Getting out made it worse

Trying to move the chat back to the real checkout failed: the move command tried to run a git command in the empty /tmp folder, which was no longer a repository. The workaround was to create a repository in the empty folder, make an empty commit and try again. That worked, but it also created a new local master branch in the real checkout, which the developer had to switch away from and delete.

What Cursor said

A Cursor staff member apologised for the lost work. They said Cursor's own worktrees are created under ~/.cursor/worktrees, not /tmp, so the /tmp folders most likely came from the agent running git worktree add itself and then moving the chat there. They said Cursor doesn't warn today when that folder is temporary, that the suggestions to show the workspace path and warn on temp folders are being shared with the team, and that the move failure is a known issue they're already tracking. They also noted that commits made in a linked worktree are stored in the main repository, so some committed work may be recoverable, but uncommitted changes in the wiped folder are gone.

Our take

This is our opinion. A temp folder is called that for a reason. If your agent picks where to put work, check where it picked. Ask for isolation through the tool's own worktree feature, commit early, and treat any agent workspace under /tmp as already deleted.