Cursor CLI past chats not showing up

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I started cursor cli after sshing into my machine and had a couple of chat sessions.
When I open cursor cli on my machine I don’t see those past chats in /resume-chat. At the same time if ssh into my machine I can see the past chats. I see that they’re present inside ~/.cursor/chats, not sure why I’m unable to access them.

CLI version - 2026.02.13-41ac335

Steps to Reproduce

  1. SSH into your host. Start cursor cli and chat.
  2. Login to your host. Start cursor cli. /resume-chat won’t show chats from your ssh session.

Expected Behavior

cursor cli should show all chats regardless of whether it was started over ssh or not.

Operating System

Linux

Version Information

CLI Version 2026.02.13-41ac335
Model Auto
OS linux (x64)
Terminal gnome-terminal
Shell zsh

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the report. A couple of questions to narrow this down:

  1. When you SSH in and when you log in locally, is it the same Linux user? Does the $HOME environment variable resolve to the same path in both cases?
  2. Are you signed into the same Cursor account in both sessions?
  3. Can you try running /resume-chat with the latest CLI and see if the issue still happens? There was a recent fix where /resume wasn’t showing sessions.

If you have files in ~/.cursor/chats in both contexts, but /resume-chat only shows them over SSH, it might be session isolation between SSH and the local terminal environment. Let me know what you find, and we can take the next step.

4
  1. Yes, it is the same user in both the cases and $HOME resolves to same path.
  2. Yes, it is the same account.
  3. Even /resume-chat does not show past chats when running locally whereas it shows past chats to choose from in the ssh session. If try to explicitly give it a folder name from ~/.cursor/chats it still says chat not found.

If it helps, the ssh client I’m using is Termius in android and OS I’m running in NixOS.

Any way to figure out why the two are being treated as different sessions by cursor even though it’s the same machine and user?

5

It’s interesting that even explicitly passing the chat folder name locally still returns “chat not found”. That’s a strong signal. A couple things to try:

  1. Update the CLI. There was a fix for /resume where sessions weren’t listed, and it shipped after your version (2026.02.13).

  2. Compare environments. Even if $HOME matches, there may be other environment variables that the CLI uses to scope sessions. Can you run env | sort > ~/env_local.txt locally and env | sort > ~/env_ssh.txt over SSH, then diff them? I’m especially interested in variables like $XDG_RUNTIME_DIR, $DISPLAY, $DBUS_SESSION_BUS_ADDRESS, or anything NixOS-specific.

  3. Check permissions and symlinks. On NixOS the filesystem layout can be unusual. Check that ls -la ~/.cursor/chats/ shows the same output in both contexts. Also check whether ~/.cursor itself is a symlink with readlink -f ~/.cursor.

Getting “chat not found” even when you pass the folder name directly is the most suspicious part. That shouldn’t happen if the files are actually accessible. Let me know what you see after updating and comparing the environments.

6

  1. It looks like I am on the latest cli version. cursor-agent update shows “Already up to date”. Also, the install script seems to be downloading the same version as mine.

    image

  2. Here’s the diff output

    image
    image1811×656 123 KB

    XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS is the same for both.

  3. ls -la ~/.cursor/chats/ shows the same output in both. ~/.cursoris not a symlink, can confirm.

1 Like
7

Hi @deanrie, any update on this? Anything else I can provide to help debug this?

8

Sorry for the delay, and thanks for the detailed diff. It’s really helpful.

I see a few potentially important differences between the environments:

  • XDG_SESSION_TYPE: x11 (local) vs tty (SSH)
  • XDG_SESSION_ID: different values (8 vs 5)
  • SSH_CLIENT / SSH_CONNECTION / SSH_TTY exist in the SSH environment

It looks like the CLI uses one of these variables to scope chats to a session, so your local session and SSH session can’t see each other.

A related /resume bug was fixed recently where sessions didn’t show up, but that fix shipped after your CLI version (2026.02.13). If cursor-agent update says “Already up to date”, it may mean the new build hasn’t been published yet.

I’ve passed this to the team working on the CLI. I’ll update the thread when I have more info. In the meantime, you can try one thing to test the theory. Run the CLI locally, but force the SSH-like variable:

XDG_SESSION_TYPE=tty agent

If /resume-chat shows your SSH chats after that, it confirms this is session scoping tied to that variable. Let me know how it goes.

9

I looked a bit more into this. If I start zsh locally as env -i HOME=$HOME TERM=$TERM PATH=$PATH zsh -f then I’m able to see the past chats.
I don’t know yet what exact env vars might be causing this.

Running XDG_SESSION_TYPE=tty agent didn’t work.

10

Great catch with env -i. That confirms some environment variable in your normal local session is making the CLI group chats differently.

XDG_SESSION_TYPE=tty didn’t help, so it’s likely a different variable. From the diff between SSH and local, the most suspicious candidates are:

  • DESKTOP_SESSION
  • XDG_CURRENT_DESKTOP
  • XDG_SESSION_CLASS
  • GDMSESSION
  • SESSION_MANAGER

Try running with a minimal env and add these one by one:

env -i HOME=$HOME TERM=$TERM PATH=$PATH DESKTOP_SESSION=$DESKTOP_SESSION zsh -c 'agent'

If adding DESKTOP_SESSION makes the chats disappear, that’s your culprit. If not, swap it for the next variable:

env -i HOME=$HOME TERM=$TERM PATH=$PATH XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP zsh -c 'agent'

And so on until you find the one causing it. Once you identify it, share it here and I’ll pass it to the CLI team.