Cursor Agent CLI hangs during startup when github.com:22 is blocked

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Cursor Agent CLI hangs during startup when GitHub SSH on port 22 is unreachable.

Running agent does not reach the normal Agent UI and shows no useful error message. Already-running Agent sessions continue to work normally.

Using strace, I found that Agent startup eventually blocks while connecting to github.com on port 22. On this network, github.com:22 times out, while port 443 is reachable.

Configuring GitHub SSH-over-443 in ~/.ssh/config immediately fixes the issue and agent starts normally again.

Steps to Reproduce

  1. Use a network where outbound SSH to github.com:22 is blocked or times out.

  2. Confirm the behavior:

ssh -vvv -o ConnectTimeout=5 -T [email protected]

Result:

Connecting to github.com [...] port 22.
connect to address ... port 22: Connection timed out
  1. Start Cursor Agent:

agent

  1. Cursor Agent hangs during startup before the normal UI appears, with no useful error message.

  2. Configure SSH-over-443:

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

  1. Run agent again.

  2. Cursor Agent starts normally.

I reproduced the original hang with these Agent versions:

  • 2026.08.25-3e8eec8
  • 2026.08.11-e8db854
  • 2026.08.04-aaa8809

Restarting WSL with wsl --shutdown did not resolve it.

Expected Behavior

An unreachable Git remote should not block Cursor Agent startup.

Cursor Agent should apply a reasonable timeout to Git/SSH remote operations, display a clear error, and continue starting without remote Git functionality when possible.

It would also be helpful to understand why Cursor Agent needs to contact the GitHub remote during startup at all.

Operating System

Linux

Version Information

Cursor Agent CLI v2026.08.25-3e8eec8

Also reproduced with:

  • v2026.08.11-e8db854
  • v2026.08.04-aaa8809

Environment:

  • WSL2
  • Ubuntu

For AI issues: which model did you use?

Not applicable. The issue occurs during Cursor Agent CLI startup before a model interaction begins.

For AI issues: add Request ID with privacy disabled

Not applicable. The issue occurs during CLI startup before any AI request is sent.

Additional Information

I traced the startup with strace.

The Agent process was scanning local Git repositories and then blocked while trying to connect to github.com on SSH port 22.

Direct testing confirmed:

  • github.com:22 → connection timeout
  • github.com:443 → reachable

After adding this to ~/.ssh/config:

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

Cursor Agent started normally immediately.

This appears similar to other Cursor CLI issues where blocked Git/SSH operations remain pending, but in this case the entire CLI startup is blocked before the normal Agent UI appears.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, @M_Y, thanks for the detailed report, and especially for tracing it all the way to the connection attempt on port 22 via strace.

You found the right spot. On startup, the CLI syncs installed plugins from their git repos, and right now this sync tries SSH first without a connect timeout. On networks where github.com:22 silently drops packets (times out instead of replying with refused), that attempt hangs and blocks the CLI startup until the UI shows up. This is an issue we’re tracking, and I linked your report to it.

Your SSH-over-443 setup is the best workaround for now. If you need another option, disabling or uninstalling installed plugins also avoids this startup sync.

I can’t share an ETA yet, but I’ll post in the thread when there’s an update.

7

@deanrie

Thanks, that makes sense — the plugin sync explains why the CLI was reaching out to GitHub during startup.

Good to know the SSH-over-443 workaround is the recommended option for now. I’ll keep that in place and wait for the fix.

Also, thanks for linking my report to the tracked issue.

8

Glad the workaround helped. Here’s SSH over 443 for now, until we ship a proper fix with a timeout and an HTTPS fallback.

I’ll post an update here as soon as we have one. Thanks again for the detailed strace write-up, it made it a lot easier to track down.