When any integrated terminal session prints output, the inline rename input for terminal sessions loses focus. This makes terminal renaming fail or become very hard to complete while another terminal is producing output.
The output does not need to come from the terminal being renamed. It can come from a different terminal session. The terminal does not need to be scrolling yet; a simple print event is enough to trigger the focus loss.
Steps to Reproduce
Open two integrated terminal sessions.
In terminal A, run: for i in $(seq 1 100); do printf '%03d\n' "$i"; sleep 0.3; done
While terminal A is printing numbers, try to rename terminal B.
Observe that the rename input loses focus as soon as terminal output occurs.
After terminal A stops printing, try renaming terminal B again.
Expected Behavior
The terminal rename input should keep focus until I press Enter/Escape or click away, even if another terminal session prints output.
Actual:
The rename input loses focus when terminal output occurs, so the rename is interrupted.
Operating System
Linux
Version Information
Cursor: 3.1.17
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Package: cursor 3.1.17-1776628399, installed via apt/deb
Hey, thanks for the detailed report. The video and clear steps help a lot.
I can reproduce it, and the bug is real. Any title-change event from a nearby terminal, and shell integration sends these a lot while a command is running, triggers a refresh of the tab list, which steals focus from the active rename input. I reported it internally.
No fix timeline yet, but the issue is logged. If there’s an update, I’ll reply in the thread.
As a temporary workaround, you can rename the terminal when nearby sessions are idle, or right click the tab and use Rename after the output stops.
Piggybacking since it feels very related: renaming Agent chats has a similar issue. If ANY agent is running while trying to rename a chat, it will more often than not steal focus which “cancels”/deletes whatever rename was partially typed.
One workaround is to pre-type the rename and quickly copy/paste, but it is awfully annoying. It feels like a classic React state bug
Similar prior reports for reference:
similar issue, although i think it was more about in-progress chats refusing to even give the rename text box, and was closed so cannot comment there "Lost focus" during chat renaming
Hey @JHWebpt, thanks for calling this out. This looks like a related bug, same class where refresh steals focus from the active rename input, but it’s in chat rename, not terminal tabs, so we’ll track it separately from the thread above.
The chat rename part while an agent is running was fixed recently. Can you share your Cursor version? Cursor Settings > About or cursor --version. I want to check if you’re on a build with the fix, or if this is a regression or a different case.
Hi, thanks for the quick response and for tracking it!
Depending on when the fix went out I may not have it yet, I got scared after reading the “delete” chat function was removed in another thread, and have not updated because of that. Here is my current version:
Version: 3.5.17 (Universal)
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z (1 wk ago)
Re the parallel open thread about renaming an agent: I do not think it is quite related, because in that case it seems the text field never appears, whereas in my case it appears and lets you type but risks suddenly disappearing and losing whatever changes were typed - while properly saving the rename if enter is pressed before it can disappear. That parallel thread, if I’m understanding correctly from the video, doesn’t even get to the point where the user could try to type
Small update for the separate tracked issue: Today when it happened again I noticed it actually saved what I had typed so far, rather than resetting back to previous value like I had claimed. It still took focus away and didn’t let me keep typing as described, but saving it is different behavior than I recall in the past where it undid what I typed. Maybe I’m just going crazy? haha anyway just wanted to update you on the actual behavior I am seeing. Sorry for spamming this issue thread up!
@JHWebpt, you’re not going crazy, that’s a valid observation. The behavior where it keeps what you typed when focus is lost, instead of reverting to the old value, is an improvement that landed in recent builds. The actual focus stealing while an agent is running is still being tracked separately, and we don’t have an ETA for a fix yet.