[Bug]: Sidebar opens and/or focusses MR every time opening a thread

[danir-de]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

When having multiple conversations with multiple MRs, the new MR auto-assign feature (I like it very much!) always force-opens the MR sidebar.

Even if it was closed 10 times before. Even if no sidebar was open before. Even if the MR is already open in a sidebar tab. Sometimes it even opens the same MR in multiple tabs (which is not possible normally via the GUI :D)

Expected behavior

It shall respect my previously opened tab (even if opening it in the background) and not force open a sidebar every time its opened.

Actual behavior

It always force opens and force focuses the conversations assigned MR.

Impact

Major degradation or frequent failure

Version or commit

0.0.41-nightly.20260916.1795

Environment

macOS 26.6

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Confirmed on current main (b900fc94e) and on shipping 0.0.42 / the reported 0.0.41-nightly.20260916.1795. All three already contain #9276, #10113, and #10610. This is a real web/desktop right-panel bug, not a wash of those PRs. Desktop embeds the same ChatView path; nothing in apps/desktop owns this.

The reporter likes server auto-link (“MR auto-assign”). The complaint is the right panel: opening a thread force-opens and force-focuses the assigned merge request, including after hide/close, including when that MR is already a tab, and sometimes as a second tab for the same MR. That matches the code. Auto-link itself is fine.

Two open paths. Both end in openProactive → upsertSurface, which always sets isOpen: true and activates the PR surface.

What the code does

ChatView.tsx watches linkedPullRequest ?? branchPullRequest (the auto-assigned / branch-detected MR from ThreadPullRequestReactor). On every active-thread effect it does two things:

1. On-entry open (shouldOpenProactivePullRequest, gated by Settings → General → Proactive panels). observeProactivePanelUserChoice resets targetKey to undefined whenever the thread key changes. The helper is then undefined → "<project>:<repo>:<n>" → true. That is fix(web): open proactive panels when entering threads #10610: “opens an existing pull request on entry.” The test in ChatView.logic.test.ts asserts exactly that. feat(web): add proactive panels #9276 originally promised historical panels stay closed on thread switches; fix(web): open proactive panels when entering threads #10610 reversed the PR half.

2. Follow a changed server link (shouldRetargetThreadPullRequestPanel). If the open surface is still the previous linked PR and the server assigns a different one, it calls openProactive even with Proactive panels off.

openProactive (rightPanelStore.ts) refuses only when userActionRevision has moved since the snapshot this effect took. #10113 added that so a hide/Files click during a turn is kept. It does not survive a thread switch:

• observeProactivePanelUserChoice re-reads getUserActionRevision when !sameThread. Hide/close already incremented the count; the next visit snapshots the new count, so expected === current and the open is allowed again.
• The revision map is not persisted (partialize writes only byThreadKey). Reload zeros it.

So “closed 10 times” is real: close is a user action on this visit, forgotten on the next.

upsertSurface has an unused activate = true default and always opens the panel (isOpen: true + focus that surface). If the MR tab already exists, it is not added again — but the panel is shown and that tab is focused. That is “already open in a sidebar tab” and “force focuses.” There is no background-add path.

Duplicate tabs are a second, mechanical bug. pullRequestSurfaceId keys on optional environmentId + optional host + project + repo + number. A click through openPullRequestLink stores host. Auto-open uses pullRequestSurface(linkedThreadPullRequest). ThreadLinkedPullRequest has url but no host, and the helper does not parse one out of url. Same MR becomes:

• pull-request:<project>:<host>:<repo>:<n> (click)
• pull-request:<project>:<repo>:<n> (proactive)

Mixing click + auto-open creates two tabs. The GUI alone will not.

Not fixed after the reported nightly. The only later ChatView touch is #12015 (worktree setup card). No open PR claims this.

Related, not duplicates

Issue / PR	Why it does not close this
Merged #9276	Added opt-in Proactive panels. Original contract: newly linked PR / completed-turn diff only; historical panels stay closed on thread switches.
Merged #10610	Made on-entry undefined → key open the existing PR. That is the “every time I open a thread” trigger. It did not add hide-across-switch, background-add, or host-stable ids.
Merged #10113	Keeps hide/Files during a turn. Revision is re-snapshotted on thread change and dropped on reload. This report is the visit after that.
Merged #9753	Empty diffs must not replace an open PR. Priority, not hide/focus.
Merged #8160	Thread ↔ PR link. The assign the reporter likes. Not the panel.
Open #9079 / #10650	Different PR UX; neither stops on-entry openProactive.

No open or merged PR stops upsertSurface from reopening/focusing, persists the hide across thread keys, or unifies host-less vs host-ful PR surface ids.

Suggested fix

Keep this as a right-panel bugfix in apps/web (desktop inherits). Do not turn off auto-link.

1. Do not treat a thread revisit as a new link. shouldOpenProactivePullRequest(undefined, key) is what fix(web): open proactive panels when entering threads #10610 added. First observation of a link on a thread (or a real project/repo/number change) may still open. Re-entering a thread whose targetKey was already that MR must not. Persist that last offered key with the panel state, or stop resetting targetKey on !sameThread when the thread already has a matching PR surface / stored key.
2. Honor hide/close across visits. Either persist userActionRevisionByThreadKey, or refuse openProactive when the matching PR surface already exists and isOpen === false (same idea as dismissedDeviceSurfaceIds). A later new link or a later turn can still offer once.
3. Do not steal focus. If the surface id is already in surfaces, call upsertSurface(..., activate=false) and do not force isOpen: true. First add may still open+focus. “Respect my previously opened tab, even in the background.”
4. One tab per MR. When building a proactive surface from ThreadLinkedPullRequest, parse host from url (or match an existing tab by projectId + repository + number, ignoring a missing host).
5. Tests next to ChatView.logic.test.ts / rightPanelStore.test.ts: hide → switch thread → come back stays closed; PR tab present with Files active → Files stays; click-with-host then proactive-without → one surface; setting off → on-entry does not open.

Do not revert #10610 wholesale if first-ever visit should still peek the PR when the setting is on. The defect is revisit / hide / focus / duplicate, not “never open.”

Workaround

Settings → General → Proactive panels off. That stops on-entry force-open. Follow-on-reassign can still steal focus if the panel is already showing the previous linked MR; hide the panel first. No in-app “open assigned MR in the background.”

Classification: bug · accepted · medium (web/desktop right panel; thread entry / auto-link force-opens and force-focuses the assigned MR)
Labels: add accepted, via-triage; keep bug; remove needs-triage
Discord tags: ui