CLI stuck on “Trusting workspace...” while a plugin marketplace Git fetch blocks startup

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

After accepting “Trust this workspace,” Cursor CLI remained on “:hourglass_not_done: Trusting workspace…” for several minutes without reaching the input prompt or displaying a download error.

The workspace trust marker had already been written successfully. While the UI still showed the trust message, the CLI had child git fetch and ssh processes fetching a plugin marketplace repository.

The problem also occurred in a newly created empty directory. Restarting in an already trusted directory still failed to reach the input prompt.

Steps to Reproduce

  1. Start cursor-agent with a Git-backed plugin marketplace configured.
  2. Open a previously untrusted directory.
  3. Press a to trust the workspace.
  4. The UI remains on “Trusting workspace…” while a marketplace fetch remains pending.

Expected Behavior

Complete the workspace trust UI once the trust decision is saved. Show plugin download progress or an actionable error if startup is waiting on a marketplace. Provide a way to skip a stalled plugin download and continue startup.

Operating System

MacOS

Version Information

Cursor CLI: 2026.09.02-c22c1a3
macOS: 26.6.2 (Apple Silicon)
Terminal: cmux
Shell: zsh

Additional Information

Sanitized process tree:

cursor-agent
└── git fetch --depth 1 --filter=blob:none origin <commit>
    └── ssh -oBatchMode=yes ... git-upload-pack '<owner>/<repository>.git'

Later inspection showed another fetch attempt for the same commit.

Removing the affected marketplace registration, terminating the stuck processes, and restarting the CLI allowed it to reach the normal input prompt. Other marketplace registrations were retained.

The underlying reason the SSH fetch stalled was not determined. A pending marketplace fetch prevented access to the CLI input prompt, while the screen misleadingly continued to show “Trusting workspace…”.

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey @AlanAhn, thanks for the detailed report’

You read it right. The trust decision was saved fine; the “Trusting workspace…” line is just the last thing drawn before the CLI moved on to syncing your installed plugins, and that sync waits for each plugin’s git fetch to finish before the prompt appears.

When a fetch stalls, startup stalls with it. This is a known issue we’re already tracking, and I’ve added your report to it.

One possible way to work around it in the meantime (besides removing the marketplace entirely): make a stalled SSH fetch fail fast instead of hanging.

Run this before starting the CLI (or add it to your shell profile).

export GIT_SSH_COMMAND="ssh -oConnectTimeout=10 -oServerAliveInterval=15 -oServerAliveCountMax=2"

The CLI should preserve keeps your GIT_SSH_COMMAND and only appends its non-interactive flags, so a dead connection would now errors out in about 30 seconds and startup continues without that plugin.

Please give that a try and let us know! It would, at a minimum, confirm we’re targeting the right mechanism.

9

Thanks! I tested CLI 2026.10.01-e373342 with an isolated profile and a project-local plugin pointing to a local SSH server that accepts connections but never sends a banner.

Without the timeout options, no input prompt appeared within 35 seconds. With your options, two fetch attempts timed out at about 10 seconds each, and the prompt appeared after 20.7 seconds.

This confirms startup recovery in that synthetic case; I haven’t retested the original remote. Fetch retries continued after the prompt appeared—is that expected?

13

Hey @AlanAhn, thanks for testing that, and for setting up the local SSH server to reproduce it. That confirms the mechanism, and I’ve added your results to the issue we’re tracking.

On the retries after the prompt: yes, that’s expected in the current version. Right after the prompt appears, the CLI does one more plugin refresh in the background, and it doesn’t remember that a fetch failed earlier, so it tries the same plugin again. Opening the plugins or marketplaces screens, or installing or toggling a plugin, also triggers a refresh and another attempt. Those retries run in the background and shouldn’t block the prompt, but a message you send while one is in flight may wait a few extra seconds before it starts.

One thing that would help: after the prompt appeared, did the retries stop after one more round, or did they keep going for the whole session without you opening any plugin screens? If they kept going, roughly how often?

For your original remote, removing that marketplace or keeping the GIT_SSH_COMMAND options in place are still the best workarounds until a fix ships.