Bug: "Element with id X is already registered" in tree views (missing upstream VS Code race-condition fix)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s still throws Error: Element with id <X> is already registered from ExtHostTreeView.createAndRegisterTreeNode, a race condition that upstream VS Code already fixed in Nov-Dec 2025. When this fires, tree views (e.g., GitHub Pull Requests) fail to render - the user sees an error and the tree is empty/stale until Cursor is restarted.

Steps to Reproduce

  1. Install GitHub.vscode-pull-request-github.
  2. Open a workspace with a lot of PRs.
  3. Expand the “Pull Requests” panel, choose “All Open” (or another large query like “All”), keep pressing “Load more” until everything disappears and error appears.
  4. Error says: Element with id <repo-path>/All Open<pr-url> is already registered.
  5. The tree items do not render until a full reload.

Expected Behavior

Rebase Cursor’s bundled VS Code core onto a version that includes those upstream VSCode fixes:

  • microsoft/vscode#281000 - “Fix element already registered” (merged 2025-12-03)
  • microsoft/vscode#281269 - “Another fix for ‘element with id not registered’ error” (merged 2025-12-04)
  • microsoft/vscode#283079 - “Reapply element already registered race condition fix” (merged 2025-12-12)

or cherry-pick those commits.

Without them every TreeDataProvider with stable TreeItem.ids (GitHub PRs, Azure resources, SFDX, etc.) is exposed to this race.

Operating System

MacOS

Version Information

Version: 3.4.17 (Universal)
VSCode Version: 1.105.1
Commit: 93e603f703cd553a6bb3644711a3379bbbb31180
Date: 2026-05-13T21:39:55.724Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

Additional Information

Inside Cursor’s extensionHostProcess.js, the ExtHostTreeView.createAndRegisterTreeNode method still throws on any duplicate handle:

createAndRegisterTreeNode(e,t,i){
  const r=this.createTreeNode(e,t,i);
  if(t.id && this.elements.has(r.item.handle))
    throw new Error(y(2918, null, t.id)); // "Element with id {0} is already registered"
  return this.addNodeToCache(e,r), this.addNodeToParentCache(r,i), r;
}

Under concurrent getChildren / refresh flows, the same element is legitimately asked to register twice. Upstream VS Code changed this path to update the existing node instead of throwing, and added fetch tokens to discard stale child-fetches.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

For those still waiting for the fix for months like me - there is a workaround that I’m using now, but it resets after every update:

Patch extensionHostProcess.js to adopt the upstream _createAndRegisterTreeNode behavior - on duplicate handle, reuse updateNodeCache + dispose (both already present in the file) instead of throwing:

createAndRegisterTreeNode(e,t,i){
  const r=this.createTreeNode(e,t,i);
  if(t.id && this.elements.has(r.item.handle)){
    const existing = this.elements.get(r.item.handle);
    if (existing !== void 0) {
      const existingNode = this.nodes.get(existing);
      if (existingNode) {
        this.updateNodeCache(e, r, existingNode, i);
        existingNode.dispose();
        return r;
      }
    }
    return r;
  }
  return this.addNodeToCache(e,r), this.addNodeToParentCache(r,i), r;
}

After applying this patch and restarting Cursor, the error toast is gone and the PR tree renders correctly.

Ask your AI to patch this for you. Of course - ask it to verify this is legit before patching anything - a lot of malicious advice is posted nowadays on the internet.

8

Hey, thanks for the ready-to-merge level report. The exact pointer to the upstream PRs #281000, #281269, #283079, the spot in ExtHostTreeView.createAndRegisterTreeNode, and the working patch really help.

I’ve filed it internally as a bug. On our side this is a missing upstream fix in VS Code core. We’ll either cherry-pick those PRs or it’ll come in with the next VS Code core rebase. I can’t give an ETA yet.

Until then, your workaround is totally valid, with the caveat that it breaks after every update like you noted. For users who don’t want to patch extensionHostProcess.js, a temporary mitigation is to run Developer: Reload Window after the error, and avoid very large PR lists by using Load more in the GitHub PRs panel.