1M tokens burned fixing: Enterprise WSL + redirected APPDATA: Cursor keeps spawning the wrong profile/Agents window, corrupting state, and burning a full day—reinstall doesn’t help

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor on Enterprise Windows + WSL2: Full Incident & UX Critique Report

Audience: Cursor staff (support / engineering / product)
Environment: Windows Cursor client 3.12.17 (commit 0fb762053c34788bb7760d5673f8a6d4c8589d50) + WSL2 Ubuntu remote (anysphere.remote-wsl)
Org context: Large enterprise with redirected APPDATA (SMB/DFS file share), dual corporate HTTP proxies, Fortinet SSL inspection
Effort: >1,000,000 tokens of agent/assistant work and an entire business day across multiple sessions to get a merely usable classic-editor workflow. This is not a one-off “user error” ticket.

Organizational note: Staff at this company routinely hit these exact same failure modes. The shared experience is a nightmare: uninstalling, reinstalling, rebooting, lighting candles and saying Hail Marys, offering up goats and our firstborn children, and even doing the hokey pokie — none of these help. The problems are structural (profile path, IPC isolation, Glass/Agents vs WSL, proxy/HTTP2, CLI flag handling), not superstition or “have you tried turning it off and on again.”

0. Executive summary

Cursor on this enterprise Windows + WSL setup repeatedly:

  1. Stores critical SQLite state (state.vscdb) on a network-redirected %APPDATA%, where it grows to ~1+ GB, corrupts, and crashes or hangs the IDE.
  2. Silently falls back to that network profile whenever a launch path omits --user-data-dir / fails to inherit VSCODE_APPDATA, including ordinary WSL cursor <path> via remote-cli (which ignores --user-data-dir).
  3. Defaults / resets toward Agents Window (Glass) layout, which does not properly support WSL, so folder opens show invalid paths, prompts stick on “Planning next moves”, and multi-repo orchestration UX is unusable.
  4. Makes WSL CLI opens fight the product: hijack existing windows, open Agents instead of editor, open “fake” remotes, or spawn a second Cursor on the wrong profile.
  5. Interacts badly with corporate proxies + HTTP/2 agent streaming and SSL inspection (self-signed certificate in certificate chain).

We spent an entire workday and over one million tokens chasing the same classes of bugs in loops because settings, layout preferences, and profile paths keep resetting or being bypassed by alternate launch paths (Start Menu vs WSL CLI vs Start-Process vs remote-cli IPC).

1. Environment facts (authoritative)

Item Value
OS Windows 10/11 + WSL2
Distro Ubuntu (WSL_DISTRO_NAME=Ubuntu; also Ubuntu-24.04 present but stopped)
Cursor 3.12.17 stable, user install under C:\Users\rpicke1\AppData\Local\Programs\cursor
%APPDATA% \\ac2knyc0206\Userdata\rpicke1\AppData\Roaming (network redirect)
Default Cursor roaming data \\ac2knyc0206\...\Roaming\Cursor
Intended healthy profile C:\Users\rpicke1\AppData\Local\CursorUserData (local NTFS)
Junction attempt C:\Users\rpicke1\AppData\Local\Cursor → CursorUserData + User env VSCODE_APPDATA=C:\Users\rpicke1\AppData\Local
Portable data/ next to Cursor.exe Does not work — product.json has "target": "user", which disables VS Code/Cursor portable detection (isPortable = !("target" in product) && exists(data))
Proxies gmdvproxy.acml.com:8080 (normal IDE/shell); proxy.acml.com:8082 (only for WSL Cursor Server install via wget)
SSL Fortinet / AB CA chain; Node needs NODE_EXTRA_CA_CERTS
Agent network mitigations applied cli-config.json → network.useHttp1ForAgent: true; settings → cursor.general.disableHttp2: true

2. Problem catalog (detailed)

2.1 Network-redirected APPDATA + gigantic / corrupt state.vscdb

Symptom

  • Cursor runs briefly then exits.
  • Corrupt DB warnings; restore from .bak / they.broke.it.
  • One-prompt-per-conversation then failure; post-reinstall still unstable.
  • IDE “Planning next moves” forever; empty/aborted transcripts.

Root cause

  • Corporate %APPDATA% is an SMB/DFS share.
  • Cursor puts SQLite (User\globalStorage\state.vscdb, WAL/SHM) there.
  • Observed sizes: ~1.3 GB on network; after local migration still ~1.1 GB on local disk (history restored from Jul 14 bak; still a landmine).
  • SQLite over network file locking is a known footgun; corruption of cursorDiskKV observed.

Nuances

  • Quarantining network DBs under ...\globalStorage\quarantine-* is necessary but insufficient: any Cursor.exe started without local UDD recreates/writes network state.vscdb again.
  • Child processes (--type=renderer|gpu|crashpad) reveal which profile is live via --user-data-dir=.... Main process command lines often omit UDD even when children show network vs local — diagnosis must inspect children, not only the top-level argv.

Mitigations attempted (repeatedly)

  • Quarantine network DB + WAL/SHM.
  • Create C:\Users\rpicke1\AppData\Local\CursorUserData.
  • Restore Jul 14 state.vscdb.bak-pre-denotation-rule (~322 composers / ~128k bubbles); merge auth from a fresh small DB; copy workspaceStorage.
  • Start Menu / desktop shortcuts with --user-data-dir=...\CursorUserData.
  • Start-Cursor-Local.cmd.
  • User env VSCODE_APPDATA.
  • Junction Local\Cursor → CursorUserData.
  • Portable Programs\cursor\data\user-data junction — blocked by product.target=user.
  • Re-quarantine network DB whenever a bad launch recreated it.

Why it kept coming back

  • Launch path diversity: Start Menu (sometimes patched), raw Cursor.exe, WSL remote-cli (ignores --user-data-dir), PowerShell Start-Process, Chrome “Cursor” PWA shortcut accidentally rewritten once, etc.
  • IPC is keyed by resolved user-data path string. Network instance and local instance are different apps from IPC’s POV. WSL cursor attaches to whichever profile remote-cli resolves — often network.

2.2 WSL cursor CLI cannot pass --user-data-dir

Symptom

Ignoring option 'user-data-dir': not supported for cursor.

Root cause

  • WSL path: resources/app/bin/cursor → remote-wsl wslCursor.sh → remote-cli/cursor.
  • CLI explicitly strips/ignores --user-data-dir for the cursor product.
  • User-data path for IPC is resolved via VSCODE_PORTABLE / VSCODE_APPDATA / default %APPDATA%\cursor — not via the ignored flag when using remote-cli.

Nuances

  • Injecting --user-data-dir into the WSL shim is a no-op for profile selection.
  • VSCODE_APPDATA via WSLENV=VSCODE_APPDATA/u sometimes fails to reach the Windows IDE process spawned through remote-cli; observed instances still using \\ac2knyc0206\...\Roaming\Cursor despite User-level env being set.
  • Therefore the only reliable open path we found for folders was: Windows Start-Process Cursor.exe with explicit --user-data-dir=C:\Users\...\CursorUserData, plus --classic, plus vscode-remote://wsl+Ubuntu/... URIs — accepting that this bypasses some remote-cli niceties.

2.3 Opening folders via Start-Process --folder-uri without a healthy local profile / remote-cli

Symptom

  • Explorer shows the folder name but “path isn’t valid” / no files.
  • Looks like a workspace but isn’t a real WSL remote session.

Root cause

  • Direct Electron argv with vscode-remote:// is fragile when Cursor is already open / wrong profile / Glass Agents surface.
  • Known community reports: --folder-uri vscode-remote://... mishandled when an instance is already running.
  • Agents/Glass does not activate WSL remote the way classic editor does (forum: “Extension WSL required” loops; Agents doesn’t support WSL properly).

Nuances

  • Same URI that works under classic + local UDD fails under Agents or network profile.
  • Workspace storage entries appear as vscode-remote://wsl%2Bubuntu/... (lowercase) while CLI emits wsl+Ubuntu — usually OK on Windows case-insensitivity, but adds confusion when debugging.

2.4 Window hijack: --reuse-window / default IPC focus behavior

Symptom

  • cursor ~/workspace/.../fiqit-model-rates steals an already-open deployments (or other) window and switches its workspace.

Root cause

  • An earlier “fix” defaulted to --reuse-window to “attach to local profile.”
  • That is the opposite of Linux/code <path> expectations (-n / new window by default).

Fix direction

  • Default --new-window for path opens.
  • Still must pair with local UDD + --classic or you get a new broken Agents/network window instead of a hijack.

Nuance

  • User expectation (straight Linux): cursor <path> always opens that path as a proper IDE window without destroying other work. Meeting that bar on Win+WSL required a custom shim and still fights product defaults.

2.5 Agents Window / Glass as default — opens instead of IDE, prompts do nothing

Symptom

  • cursor <path> opens Agents Window, not classic editor.
  • Path not really opened / invalid.
  • Agent prompts stuck on Planning / “planning next moves” for hours; transcripts empty or User aborted request with no tool activity.
  • Meanwhile classic editor in another workspace can still work (e.g. Fiquants/ai healthy while deployments hung — often while still on network profile).

Root causes (compounding)

  1. Layout preference stored in SQLite, not only settings.json:
    • cursor/unifiedAppLayout = 'agent'
    • cursor/agentLayout.forceToAgentLastValue = 'true'
    • cursor/userOpenAgentsWindowOnStartupPreference (always/never/default)
  2. CLI opens without --classic route into Glass.
  3. Agents/Glass does not properly support WSL remotes (Cursor forum / docs guidance: use Editor / --classic for WSL).
  4. HTTP/2 streaming through corp proxy stalls agent turns → “Planning” forever (mitigated with HTTP/1 flags, but Agents+WSL still broken).
  5. After kill/restart, layout can feel “reset” if a network profile instance comes up (fresh/default Glass) or if local DB still has unifiedAppLayout=agent.

Nuances

  • --classic is documented as forcing classic windows; on some versions / Glass builds, CLI folder opens still get hijacked by Agents routing (community bug reports).
  • Changing layout in state.vscdb requires Cursor not holding the DB; stopping all Cursor processes to write preferences closes every open window (user-visible data loss of session layout — happened during remediation).
  • product.target=user blocks portable mode, so profile pinning is forever argv/env fragile.

2.6 Agents Window UX does not meet “orchestrate many agents” (product/UX)

Even when Glass opens, it fails the orchestration job:

  • No multi-conversation visibility analogous to IDE split editors (cannot see two prompt threads at once).
  • No global “most recent / active” conversation list across repos for one-click hopping.
  • Repo-grouped sidebar: one repo with a large history expands and buries other repos’ active chats; user must scroll / collapse-expand groups.
  • Feels like a per-repo chat archive, not a multi-agent control surface.
  • Multi-root workspaces in Agents: reported weak/missing for WSL folders on forum.

This is separate from reliability bugs but central to “why did we spend a day fighting Glass.”

2.7 Proxy / SSL / HTTP2 agent hangs

Symptom

  • Second prompt hangs on planning.
  • Indexing / agent TLS: self-signed certificate in certificate chain.
  • Sudden disconnects / CLI death mid-stream.

Root causes

  • Dual proxies; wrong proxy used for wrong purpose caused confusion:
    • proxy.acml.com:8082 — WSL server component install (wget) only.
    • gmdvproxy.acml.com:8080 — normal operation.
  • Early remediation briefly flipped settings/bashrc to 8082 for “everything,” then had to be corrected back.
  • Fortinet MITM requires AB CA chain in NODE_EXTRA_CA_CERTS (~/.certs/node-extra-cas.pem).
  • HTTP/2 agent streams stall through corp proxies → force HTTP/1 (useHttp1ForAgent, cursor.general.disableHttp2).

Nuances

  • Settings can differ between network profile Roaming\Cursor\User\settings.json and local CursorUserData\User\settings.json. Fixing one does nothing if the live instance uses the other.
  • Opening entire $HOME as workspace (~346k files, .npm cache, .ssh, etc.) compounded load (.cursorignore mitigations). Orphaned extension hosts / stale cursor-server also observed.

2.8 Settings / profile “resets” and dual-instance confusion

What “reset” means in practice (not mystical — mechanical):

  1. User launches Cursor via a path without local --user-data-dir → network profile (empty/fresh or half-quarantined) → appears as “settings wiped / Agents default / prompts broken.”
  2. User launches via Start Menu with local UDD → healthy classic settings return — “settings came back.”
  3. WSL cursor remote-cli attaches to whichever instance owns the IPC socket for the CLI-resolved user-data path — often the wrong one if both exist.
  4. Two Cursor trees can run concurrently:
    • Local: --user-data-dir=C:\Users\...\CursorUserData
    • Network: \\ac2knyc0206\...\Roaming\Cursor
  5. Layout keys in SQLite (unifiedAppLayout=agent) make Glass return even on local disk until explicitly flipped to editor and --classic is forced on CLI.
  6. Shortcut edits are fragile (Start Menu under redirected Roaming; OneDrive Desktop; accidental overwrite of Chrome App “Cursor.lnk”).

Staff implication: From the user’s POV, Cursor “keeps resetting.” From engineering’s POV, multiple user-data roots + CLI ignoring UDD + Glass default = intermittent alternate universes.

2.9 Chat history recovery asymmetry

  • Pre–Jul 14 IDE history recoverable from bak into local profile.
  • Later corrupt network DB: message bodies unreadable (cursorDiskKV malformed).
  • WSL ~/.cursor/projects/**/agent-transcripts/*.jsonl survive on disk but are not an official import path into IDE chat UI.
  • Killing Cursor to patch SQLite layout prefs destroys open window set; restoring workspaces is manual (Start-Process per folder/workspace).

2.10 Custom shim debt (required to approximate Linux behavior)

To approximate cursor <path> on Linux we ended up with:

  • ~/.local/bin/cursor — forces classic + local UDD open helper for paths; cursor agent → CLI agent; pass-through for tunnel/help.
  • ~/bin/cursor-open-workspace — PowerShell Start-Process with --user-data-dir, --classic, --new-window, --folder-uri/--file-uri, --remote=wsl+Ubuntu.
  • Start-Cursor-Local.cmd — Windows entry with --user-data-dir + --classic.
  • Regenerated / reverted make_code_links.sh / code-* launchers multiple times while discovering remote-cli vs Start-Process tradeoffs.

This should not be necessary. It is unpaid enterprise support work pushed onto the customer.

3. Timeline shape (why “entire day / 1M+ tokens”)

Rough loop repeated across sessions:

  1. Diagnose crash/hang → find network SQLite / proxy / huge workspace.
  2. Move profile local → works briefly.
  3. Open from WSL CLI → attaches to / spawns network or Agents instance → broken again.
  4. Patch shim / shortcuts / env → different failure (hijack, invalid path, Planning hang).
  5. Kill all Cursor to edit state.vscdb layout → user loses all windows → restore set → profile drifts again.
  6. Document Agents UX failure as product issue on top of reliability.

Each loop burns large context (logs, process dumps, SQLite, forum research, shim rewrites). Aggregate >1M tokens, multi-session full workday.

4. What Cursor should treat as bugs / product gaps

Reliability / platform

  1. Do not store SQLite user state on redirected %APPDATA% without detecting remote/profile paths — or document mandatory --user-data-dir / support VSCODE_APPDATA consistently through remote-cli and WSL.
  2. Honor --user-data-dir in WSL remote-cli (or provide an equivalent that remote-cli cannot ignore).
  3. Single-instance profile coherence: refuse to silently start a second profile when one local UDD instance exists; or make WSL CLI always target the same resolved path as the Start Menu launcher.
  4. WSL support in Agents/Glass — either make it real or never route cursor <wsl-path> into Agents; default WSL opens to classic editor.
  5. HTTP/2 through corp proxies: default or auto-fallback to HTTP/1 when streams stall; surface errors instead of infinite “Planning.”
  6. Portable/data folder: either support user installs or document that target:user disables it (we wasted time on a dead path).

Agents Window UX (orchestration claim vs reality)

  1. Global Recent / Active conversation list across repos.
  2. True multi-pane or pinned always-visible active threads (orchestration ≠ single-transcript archive).
  3. Repo grouping must not bury other repos’ active work under one project’s history.
  4. WSL multi-root / remote parity for Agents.

5. Current brittle “working” configuration (as of remediation)

  • Live profile: C:\Users\rpicke1\AppData\Local\CursorUserData only (verify via child process --user-data-dir).
  • Network roaming DB quarantined when discovered.
  • Path opens: custom shim → Start-Process with --user-data-dir + --classic + --new-window + vscode-remote://wsl+Ubuntu/....
  • Layout SQLite: unifiedAppLayout=editor; Agents-on-startup preference never (false); forceToAgentLastValue=false.
  • useHttp1ForAgent: true; cursor.general.disableHttp2: true; Fortinet CA via NODE_EXTRA_CA_CERTS.
  • Proxy: gmdvproxy:8080 for normal use; proxy:8082 reserved for server install wget.

This is not “fixed.” It is a pile of local workarounds that will break on Cursor update, shortcut reset, accidental Cursor.exe double-click, or another env that doesn’t pass UDD.

6. Ask of Cursor staff

  1. Reproduce with: Windows + WSL2 + %APPDATA% on a UNC share + cursor /home/.../repo from WSL while a local-UDD classic window is already open.
  2. Confirm remote-cli ignores --user-data-dir and document/fix profile selection for WSL.
  3. Stop routing WSL folder opens into Agents until WSL works there.
  4. Treat network-APPDATA SQLite as a supported enterprise scenario or hard-warn / auto-relocate.
  5. Fix Agents sidebar for real multi-repo active-work orchestration (recent/active list; don’t bury chats).
  6. Acknowledge that “reinstall Cursor” does not address root causes (1)–(5); our entire org already learned that the expensive way.

7. Tone / reality check for prioritization

This report is long because the failure surface is long. Enterprise Windows + WSL + proxy is not exotic — it is how a large fraction of professional developers run Cursor. Burning a full day and over a million tokens to keep the editor from opening the wrong window on the wrong disk profile, while Agents marketing claims multi-agent orchestration it cannot UX-deliver, is an unreasonable tax on customers. Please fix the platform seams; the rituals (reinstall, reboot, candles, goats, firstborn, hokey pokie) have been exhausted and do not work.

Steps to Reproduce

detailed above

Expected Behavior

I expect the app to not suddenly close, and I expect it to be able to execute prompts.

Operating System

Windows 10/11

Version Information

Cursor: 3.12.17 (user setup)
VSCode Version: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Real Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d52
Date: 2026-07-17T02:53:53.006Z
Quality / Build Type: stable
Release Track: Default
Target: user
Layout: glass (Agents Window) and classic editor (both involved)
Electron: 40.10.3 (from process annotations)
Arch: x64
OS: Windows_NT 10.0.22631 (Win11 23H2-class)
WSL: 2
WSL distro (active): Ubuntu (Ubuntu 24.04.4 LTS)
WSL kernel: 6.18.33.2-microsoft-standard-WSL2
Remote extension: anysphere.remote-wsl 1.0.13
Cursor Server commit (WSL): 0fb762053c34788bb7760d5673f8a6d4c8589d50
Node (WSL shell): v24.5.0
cursor-agent (local CLI versions present): 2026.07.17-3e2a980 (also 2026.05.16-0338208, 2026.05.05-84a231c)

Also applicable for the report body (not product “versions,” but environment labels staff ask for):

• %APPDATA% redirected to UNC: \ac2knyc0206\Userdata\rpicke1\AppData\Roaming
• Local profile used for remediations: C:\Users\rpicke1\AppData\Local\CursorUserData

For AI issues: which model did you use?

No models work. auto, composer 2.5 fast/no-fast, grok, etc… if it’s broke, it’s broke.

Does this stop you from using Cursor

Yes - Cursor is unusable

8

Hey Richard,

A few things to make it less brittle:

  • Profile: keep the user-data dir on local NTFS (as you are). A network-redirected %APPDATA% for the SQLite DB is effectively unsupported. Pick one pin and use it everywhere: VSCODE_APPDATA takes precedence over --user-data-dir, so running both is what creates the “two profiles” drift.
  • WSL folder opens: use cursor -n <path> or cursor --classic <path> (or Open Editor Window) to force the classic editor and stop the hijack/Glass routing, and set Open Agents Window on Startup to Off. The remote-cli ignoring --user-data-dir is inherited from upstream VS Code, so the env var is the pin on that path.
  • Proxy/SSL: your mitigations are the right ones. The most durable fix is having IT exempt the Cursor domains from SSL inspection (network config).

The Agents Window orchestration points are best tracked in your other thread. The recurring issues here are ones we’re already tracking, and the two newer gaps you flagged (a warning when the profile resolves to a network share, and a profile pin that survives the WSL CLI) I’m taking to the team.

Happy to dig into any specific launch path if something above doesn’t hold.

9

thanks for your response, here’s a radical idea: instead of waiting for your team to prioritize, diagnose, and build the fix, release it, and wait for your customers to download the update, let’s cut all that time down to zero.

Agent just fixed my setup. Ergo agent can fix everyone’s setup.

We just need to provide them with a prompt.

Instead of posting bullet points in a chat like this, which can come off like “go do all these manual steps,” you can just as easily have provide a prompt we can run in agent that would audit and affect that entire change.

Any future customer having issues can just copy/paste the prompt and have their setup immediately audited for known fail states and remediated on the spot.