Possible stale Cursor sandbox state after CLI exit contributed to deletion of a workspace used by OMP

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I hit a local data-loss incident that may involve Cursor sandbox state persisting after the Cursor CLI exited and then being inherited by another terminal agent.

I want to be very careful about attribution here: I cannot prove Cursor issued the final deletion. Another agent (OMP) generated the unsafe recursive cleanup command. The reason I’m posting here is that Cursor-specific sandbox state was still present later in the execution path, and I’m trying to determine whether that could have contributed.

I’m not trying to assign blame here—I mainly want to determine whether this is an expected behavior, a bug, or simply an unfortunate interaction between two tools. If there’s any additional logging or diagnostics I can collect to help narrow this down, I’m happy to do so.

Steps to Reproduce

What happened

I ran Cursor CLI in:

/home/jmn/CLIProxyAPI

Cursor exited after I pressed Ctrl+C at:

2026-07-09 18:51:57 UTC

Fourteen seconds later, I launched OMP from the same terminal in the same repository:

2026-07-09 18:52:11 UTC

OMP later spawned several non-isolated workers. One of those workers generated:

TMPDIR=$(mktemp -d)
export PI_MODELS="$TMPDIR/models.json"
export OPENCODE_CONFIG="$TMPDIR/opencode.json"

# ...tests...

rm -rf "$TMPDIR"

The worker should never have reused the reserved TMPDIR variable. That’s an OMP bug, and I’m filing that separately.

After that cleanup, later commands started failing with:

mktemp: failed to create file via template
‘/home/jmn/.cache/tmp/tmp.4tfX7fcJGP/tmp.XXXXXXXXXX’:
No such file or directory

Within roughly 15 seconds, the entire repository directory disappeared.

Timeline (UTC)

  • 18:51:57.003 — Cursor session exits/disposes
  • 18:52:11.701 — OMP starts in the same terminal and repository
  • 19:26:58.807 — OMP worker performs the unsafe TMPDIR cleanup
  • 19:26:59.962 — Watcher still sees the repository
  • 19:27:15.686 — Watcher reports the repository root is missing
  • 19:27:21.491 — Next command fails because the working directory no longer exists

The later shell execution wrapper still contained Cursor-specific state:

__CURSOR_SANDBOX_ENV_RESTORE
dump_zsh_state

The affected temporary path was under:

/home/jmn/.cache/tmp/

Earlier Cursor logs also show that cursorsandbox was active:

sandbox.configureSuccess
sandboxBinary:
/home/jmn/.local/share/cursor-agent/versions/
2026.07.08-0c04a8a/cursorsandbox

What I know

  • Cursor CLI ran in the same repository and terminal immediately before OMP.
  • Cursor exited only 14 seconds before OMP started.
  • Cursor-specific sandbox restoration hooks appeared in the later shell execution path.
  • The sandbox temporary directory became invalid.
  • The repository disappeared shortly afterward.
  • I have no recorded command that explicitly ran:
rm -rf /home/jmn/CLIProxyAPI

What I don’t know

  • I don’t know which PID issued the final unlink/rmdir syscalls.
  • Cursor’s visible logs don’t show an explicit cleanup event at the time of deletion.
  • I cannot prove Cursor’s sandbox helper deleted the repository.
  • I also haven’t yet reproduced this from a completely fresh terminal with no prior Cursor session.

My current working theory is that this was a cross-runtime interaction:

  1. Cursor initialized sandbox/shell state.
  2. Cursor exited.
  3. OMP launched from the same terminal and inherited (or replayed) Cursor-specific shell state.
  4. An OMP worker corrupted or deleted a sandbox-managed temporary directory.
  5. A later cleanup path removed a broader directory than intended.

Step 5 is the part I cannot currently prove.

Expected Behavior

Cursor $TMPDIR state not persisting after exit.

Questions for the Cursor team

  1. Can __CURSOR_SANDBOX_ENV_RESTORE (or related shell state) remain active after the Cursor CLI exits?

  2. Can another terminal application launched afterward inherit Cursor sandbox restoration hooks?

  3. What cleanup occurs if a sandbox-managed TMPDIR is deleted or becomes invalid?

  4. Are any cleanup paths derived from mutable state like TMPDIR, the current working directory, or restored shell state?

  5. Are cleanup targets canonicalized and verified to remain underneath the intended sandbox root before deletion?

  6. Is there a diagnostic command or debug mode that can tell whether a shell still has active or stale Cursor sandbox state after the CLI exits?

Operating System

Linux

Version Information

Cursor details

Installed Cursor agent version:

2026.07.08-0c04a8a

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey,
The Cursor sandbox couldn’t have issued that deletion, and it can’t leak live state into a process launched after the CLI exits. The rm -rf "$TMPDIR" from the OMP worker is what removed the directory.

Two things worth correcting:

  • ~/.cache/tmp isn’t ours. Cursor’s sandbox never sets $TMPDIR and never touches ~/.cache/tmp; its temp dirs are ephemeral, created under /tmp, process-scoped, and removed on exit. So the failing mktemp path and the reused TMPDIR point at OMP or your environment.
  • __CURSOR_SANDBOX_ENV_RESTORE and dump_zsh_state are leftover text by then, not active state. The restore var only ever holds proxy export lines (no rm, no TMPDIR) and only lives inside the short-lived shell the CLI spawns per command — never exported to your terminal, gone when the CLI exits. Those snippets can end up in shell history or command output (a cosmetic artifact we’re aware of), which is the likely reason they resurfaced.

Your six, briefly:
(1) No, it dies with the CLI
(2) No, a later tool inherits the terminal’s env, which the CLI’s per-command shell never touches
(3) No sandbox $TMPDIR, and nothing under ~/.cache/tmp is ours
(4) No cleanup is derived from $TMPDIR, CWD, or restored shell state
(5) Cleanup targets are fixed /tmp paths, never your repo
(6) In a fresh terminal, run echo "$__CURSOR_SANDBOX_ENV_RESTORE"; typeset -f dump_zsh_state; env | grep -i cursor — all empty means no live Cursor state.

As a general safeguard regardless of which tool runs commands, add Shell(rm) to the deny list in your CLI permissions so destructive removals always prompt. Happy to dig further if that check turns up anything.

7

Thank you so much for your reply; it’s really rare to see customer support this responsive, not to mention out in the open for all to benefit from. Your third point 100% confirms the Cursor artifact was a coincidence and red herring, and it is a relief to hear that variable is confined to Cursor’s temporary shell. A search of OMP’s issues revealed a similar issue (#863) filed was closed without an apparent fix, so my suspicion is this is a failure to isolate subagent sandboxes.

On the other hand, I still cannot for the life of me determine how that variable resolved to my entire repo rather than that .cache file, making me think the rm itself may be a red herring.

In any event, your suggestion to nip the issue in the bud and install something to guard rm seems to be the best ounce of prevention for situations like these. I’ve gone ahead and aliased rm totrash-cli so things like this don’t happen irreversibly.

Thanks again and love the product!