Cursor user says agents kept putting work in a macOS temporary folder that the system then wiped, losing about 16 hours of work (first-person)
A post on the Cursor community forum on 24 October 2026 by a self-described heavy Cursor user on macOS says that over the previous week Cursor agents repeatedly created isolated git worktrees in the system temporary folder /tmp, bound the chat workspace to that path, and kept working there. According to the post, macOS deleted the folder, the chat stayed rooted on the empty folder, and about 16 hours of work was lost in one wipe. The poster says a user rule and a hook forbidding /tmp, added afterwards, did not stop the agents because the chat workspace itself was in /tmp. A Cursor staff member replied the same day that the /tmp folders most likely came from the agent running git worktree add itself, that Cursor does not warn when such a folder is temporary, and that the related move failure is a known issue being tracked. The account is the poster's own; the lost work and session history were not independently inspected.
- AI system
- Cursor coding agent
- Occurred
- Oct 2026
- Reported
- 24 October 2026
- Event location
- Unknown
- What the AI did
- Acted on the person’s behalf
- Reported harm
- Other Material Harm
- Whose AI use
- Their own AI use
- Setting
- Work
- Evidence
- AI involvement reported · Causal attribution alleged · 1 source
- 5 claims: 2 documented, 3 reported. 4 open questions
- People reported harmed
- 1 person
AI system as recorded: Cursor IDE 3.27.12 (arm64) agents on macOS 15.7.1, across multiple long-running agent chats and subagents (the poster says the behaviour was not specific to one model)
What Happened
What the poster describes. The poster, who works on a large git repository with a live local checkout under a durable folder, says agents asked to work on a new branch without disturbing that checkout created isolated git worktrees under /tmp (for example with git worktree add into a /tmp path) and that Cursor then bound the conversation to that path. The poster calls this a habit across many chats and says subagents also picked /tmp as the safe place.
The loss. According to the post, macOS deleted the /tmp folder through reboot or periodic cleanup, the uncommitted work there was gone, and the poster lost about 16 hours of work in one wipe. The chat still looked like a normal project, and the poster says the problem became visible only on asking the agent.
After the loss. The poster says a user rule and a hook forbidding /tmp were added, but agents kept using it because the chat workspace itself was in /tmp. The poster also reports that the product's move-agent-to-root tool failed on the empty folder until a workaround was used, and that the workaround switched the destination to an unwanted branch.
Vendor reply. A Cursor staff member wrote that Cursor's own worktrees go under the user's home folder, that the /tmp folders most likely came from the agent running git worktree add itself, and that Cursor does not warn when the folder is temporary. The reply calls the move failure a known issue.
Reported harm
The poster says about 16 hours of work was lost when macOS cleaned the temporary folder in which Cursor agents had placed it (first-person forum post; uncorroborated).
Outcome
OngoingA Cursor staff member apologised for the lost work, said the temporary-folder worktrees most likely came from the agent running git worktree add itself, said the worktree location is not configurable yet, suggested using the product's own worktree option, noted that commits made in a linked worktree may survive in the main repository while uncommitted changes cannot be recovered that way, and said the move failure is a known issue being tracked. No further reply from the poster appeared when the thread was read on 25 October 2026.
What remains unknown
- Exactly when in the week before 24 October 2026 the wipe happened.
- Whether any committed work survived in the main repository, as the staff reply suggests may be possible.
- Which models the agent chats used; the poster says the behaviour was not specific to one model.
- Where the poster is based.
What the evidence supports
AI involvement: reported. The post states what the agents did on the poster's machine: they ran git worktree add into /tmp for durable work, Cursor bound the chat to that path, and the agents kept working there, including after a rule and hook forbade it. The poster connects the agents' choice of folder to the loss of about 16 hours of work when macOS cleaned it. A Cursor staff member's reply says the folders most likely came from the agent running git worktree add itself. The session history was not inspected.
5 claims: 2 documented, 3 reported. What the statuses mean
Reported The poster says that over the previous week Cursor agents repeatedly created isolated git worktrees under /tmp for durable project work and that Cursor bound the conversation to that path.
Causal attribution. The poster's own account of the agents' actions; the session history was not inspected.
- forum.cursor.com(opens in new tab) supports · English
'Over the last week Cursor agents repeatedly put durable project work in'; 'To avoid checking out a branch on top of my live IDE folder, agents create isolated git worktrees in'; 'Cursor then bound the conversation to that path.'
Reported The poster says macOS deleted the folder and about 16 hours of work was lost in one wipe, including uncommitted work and commits made only in that folder.
Causal attribution. The poster attributes the loss to the agents placing durable work in a folder the operating system cleans; the amount of work is the poster's estimate.
- forum.cursor.com(opens in new tab) supports · English
'I lost about 16 hours of work in one wipe.'; 'Reboot and periodic cleanup delete it.'; 'That is the 16-hour loss.'
Reported The poster says a user rule and a hook forbidding /tmp, added after the loss, did not stop the agents because the chat workspace itself was in /tmp.
Causal attribution. The poster's account.
- forum.cursor.com(opens in new tab) supports · English
'After that I added a user rule and a hook forbidding'; 'Agents kept using it anyway because the chat workspace itself was'
Documented A Cursor staff member replied that the /tmp folders most likely came from the agent running git worktree add itself, that Cursor does not warn when the folder is temporary, and that the move failure is a known issue being tracked.
Causal attribution. The staff reply documents the vendor's own explanation; it hedges the origin of the folders as most likely and does not inspect the poster's sessions.
- forum.cursor.com(opens in new tab) supports · English
'most likely came from the agent running git worktree add itself, after which the agent moved the chat into that folder.'; 'Cursor doesn’t warn today when that folder is a temporary location'; 'The move failure is a known issue we’re already tracking'
Documented The staff reply says commits made in a linked worktree may survive in the main repository but uncommitted changes in the wiped folder cannot be recovered that way.
Causal attribution. Vendor guidance in the thread; whether any of the poster's commits survived is not stated.
- forum.cursor.com(opens in new tab) supports · English
'commits made in a linked worktree are stored in the main repo'; 'Uncommitted changes in the wiped folder can’t be recovered this way.'
Sources
1 source inspected. Sources that repeat one account do not corroborate each other.
- Cursor community forum, 24 October 2026: agents putting worktrees in /tmp by default can wipe days of work on macOS(opens in new tab)
s1 · forum.cursor.com · First person account · English · Inspected · 24 October 2026 · Primary
How the sources were read, and where the events happened
Read in English on 2026-10-25 through the Discourse JSON API (both posts). No translation was needed; the research agent (an AI) read the text directly. Applies to s1.
Event countries: Unknown. Affected-person countries: Unknown. Court countries: Unknown.
The post names macOS and the Cursor version but no place; no country is recorded.
Reviewed for publication 2026-10-25: Published under the charter's first-person rule and the 2026-10-11 repetition rule: the agents chose an operating-system temporary folder for durable work and kept using it after a rule forbade it, and the poster lost about 16 hours of work, a failure mode the published coding-agent data-loss rows (deletion commands) lack. A vendor staff reply gives the vendor's explanation. The loss is attributed to the poster throughout.
People described
A heavy Cursor user on macOS working on a large git repository with a live local checkout
People reported harmed in this case
1 person
1 AI participant · 0 other people harmed
One person: the Cursor user who says about 16 hours of work was lost in one wipe. Exact 1. No other person is described as affected.
Counted once within this case. The same person may appear in other cases. This count does not establish AI causation.
Cite this case
Compiled per our published methodology: verification statuses, sourcing standards, and corrections process.
APA
NOPE. (2026). Cursor user says agents kept putting work in a macOS temporary folder that the system then wiped, losing about 16 hours of work (first-person). AI incidents. https://nope.net/incidents/2026-cursor-agents-put-git-worktrees-in-macos-tmp-folder-system-cleanup-wiped-about-16-hours-of-work-first-person
BibTeX
@misc{2026_cursor_agents_put_git_worktrees_in_macos_tmp_folder_system_cleanup_wiped_about_16_hours_of_work_first_person,
title = {Cursor user says agents kept putting work in a macOS temporary folder that the system then wiped, losing about 16 hours of work (first-person)},
author = {NOPE},
year = {2026},
howpublished = {AI incidents},
url = {https://nope.net/incidents/2026-cursor-agents-put-git-worktrees-in-macos-tmp-folder-system-cleanup-wiped-about-16-hours-of-work-first-person}
} Related cases
Cursor forum post: an agreed cleanup delete command ran beyond the intended folder and wiped a six-month project and its backups on a Windows drive, user says
In a bug report posted to the Cursor community forum on 3 October 2026, a user says that during a clean-up of a .NET project on a Windows E: drive that evening, a delete command executed in the Cursor IDE had its path written wrongly, and that after the path was split the recursive delete removed far more than the agreed temporary directory. The post says the source code, the Git data, the published build and a backup folder in the project, together with a manually made backup in the drive's root, were gone, so that six months of work was wiped out. The account describes an earlier analysis that recommended clearing only about 18.5 GB of compilation temporaries and the user agreeing to that batch. Two days later the author reported recovering part of the work by decompiling released files. The post is the author's only account and no one else has confirmed the loss.
PocketOS: a Cursor coding agent running Anthropic's Claude Opus 4.6 deleted the car-rental software startup's production database and its volume-level backups on Railway in a single nine-second API call on 24 April 2026; customers lost reservations and sign-ups and some could not find records for renters collecting vehicles before Railway restored the data
On Friday 24 April 2026 a Cursor coding agent, running Anthropic's Claude Opus 4.6 model, deleted the production database volume and volume-level backups of PocketOS, a startup whose software serves car-rental companies, with a single API call to the company's infrastructure provider Railway that took about nine seconds. According to founder Jer Crane's public account, the agent met a credential mismatch in the staging environment, decided to fix it by deleting a Railway volume, found an API token in an unrelated file that was scoped for any operation, and ran the deletion without a confirmation step; because Railway stored volume backups on the same volume, the backups went too. Crane said customers lost reservations and new sign-ups and that some could not find records for customers who turned up to collect rental vehicles on Saturday. Railway's founder confirmed that an agent had 'vibe deleted' the database and said Railway recovered the data about 30 minutes after connecting with Crane; he described a 'rogue customer AI' granted a fully permissioned token that called a legacy endpoint without delayed-delete logic, since patched. Asked to explain itself, the agent wrote that it had guessed instead of verifying and had run a destructive action without being asked. Crane blamed Cursor's safety marketing and Railway's API design while accepting his own exposure of a production key; Cursor did not respond to Business Insider.
Forum report: a quoting error in a Cursor agent delete command wiped a user's entire D: drive (chat history, projects); Cursor staff say they found the run
In a report posted to the Cursor community forum on 9 October 2026, a user says that the Cursor agent, running in autonomous Agent mode, executed a Windows cmd command meant to delete one deprecated project directory, and that because cmd.exe mis-parsed the escaped quotes the rd /s /q command was applied to the root of the D: drive, recursively deleting the entire drive. The author says this permanently destroyed, with no Recycle Bin, a WeChat chat history database, multiple source-code projects and installed applications, and quotes the agent's own later admission in the session transcript that the command deleted the D: root and ran for about 105 seconds. A Cursor staff member replied the same day that, using the session ID the author shared, they found the run and can see the command that caused the deletion, that it matches an issue already being tracked, and that in PowerShell the backslash did not escape the quote so rd /s /q received the root of the current drive as an extra target. The event date is not stated and the extent of recovery is unknown.
First-person post in a DoorDash drivers' forum: driver says AI support kept them from an agent for 30 minutes, then unassigned the wrong order
In a Reddit post on 23 October 2026 in a forum for DoorDash drivers, a delivery driver writes that a Red Card decline that day cost them 45 minutes: an AI help line would not put them through to an agent for 30 minutes, then unassigned the wrong order from a run of three shop-and-deliver orders, and a human took another 15 minutes to put it right. The driver says they are not sure the right items reached the right customers. The post does not name the platform or the system. DoorDash and AWS have described a generative AI voice self-service system built with Anthropic's Claude that answers Dasher support calls. The account is uncorroborated and no platform response is reported.
If you or someone you know is struggling, free and confidential support is available. Find a helpline near you at Signpost.