Cursor AI tab completion (ghost text) only works in cell 1, not cells 2+

[adamjeisen]

Describe the bug

Cursor's AI inline tab completion (ghost-text / "Tab" completions) only triggers in the first cell of a marimo notebook. Typing in cells 2 and beyond produces no inline suggestions at all.

This reproduces with a notebook of any size (tested with 6 cells). The issue is present in the published extension (0.11.4). Notably, Jupyter notebooks work correctly in all cells — so this appears to be specific to marimo's notebook implementation.

Steps to reproduce

1. Open any .py marimo notebook with 2+ cells in Cursor
2. Click into cell 1 and start typing — ghost-text completions appear ✓
3. Click into cell 2 and start typing — no completions appear ✗

Expected behavior

Cursor AI tab completion triggers in all cells, not just cell 1.

Suspected root cause

This hasn't been fully diagnosed, but here's what we've found so far.

Cursor's tab completion (CPP) service registers a onDidChangeContent listener for each notebook cell editor. When content changes, it runs a deduplication check along the lines of:

modelListeners.get(relativePath).size > 1 && editor.getId() !== getActiveCodeEditor()?.getId()

Because all marimo cells share the same notebook file's relative path (e.g. demo.py), size equals the total number of cells and is always > 1. This means completions only fire for whichever cell Cursor considers the "active code editor."

Cell 1 works because it is auto-focused when the notebook opens. The hypothesis is that when switching to cells 2+, something about how marimo notebook cells are initialized or focused doesn't update Cursor's internal active-editor state in time — so the check always evaluates against cell 1's editor ID. Jupyter notebooks may work because their cell editors update this state differently (possibly due to VS Code's built-in Jupyter handling, or the Jupyter extension doing something explicit on cell focus).

We attempted a workaround — registering onDidChangeNotebookEditorSelection and calling showTextDocument(cell.document, { preserveFocus: true }) on cell selection to eagerly update the active editor — but this caused visible UI flickering without fixing the problem, suggesting the mechanism is deeper than simple active-editor tracking.

The root cause may lie in how marimo cell editors are registered with VS Code's ICodeEditorService, how focus events propagate for the marimo-notebook type, or a timing difference between when onDidChangeContent fires and when the active editor state is updated. A comparison of how Jupyter vs. marimo notebook controllers and serializers set up cell editors would likely be revealing.

Environment

• Cursor (latest)
• marimo VS Code Extension 0.11.4
• macOS 15 (Apple Silicon)