[Feature]: Edit Jupyter notebooks (.ipynb) cell by cell

[josephv123]

Problem

Agents edit .ipynb files all the time (Claude has a dedicated NotebookEdit tool, and the other providers edit the JSON directly), but in T3 Code a notebook is a large JSON file. You can't easily read what the agent changed, and making a small fix yourself, like editing a markdown cell or changing a parameter before asking the agent to continue, means hand-editing JSON in the Files panel. This is especially painful remotely (T3 Connect or mobile), when the machine with Jupyter isn't the one in front of you.

#11033 proposes a read-only .ipynb preview and explicitly leaves editing as a separate proposal. This is that proposal. It builds on #11033 and should land after it.

Proposed scope (v1)

Cell-level editing of the notebook's source, built into the existing Files preview/editor:

• Render cells (markdown, code, raw) with saved outputs, as in [Feature]: Read-only `.ipynb` notebook preview #11033.
• Edit a cell's source in place: code cells get the existing code editor with the kernel language, and markdown cells toggle between rendered and source like .md files do today.
• Add, delete, and move cells, and change a cell's type.
• Save through the existing projects.writeFile / save-coordinator path, keeping the original JSON formatting (indent, key order, nbformat metadata) so diffs stay small and git-friendly.
• A "view raw JSON" toggle as the escape hatch.

Explicitly out of scope

• Running cells or managing kernels. That would add a Jupyter runtime and process lifecycle to the server. The agent can already run jupyter nbconvert --execute or similar through its shell. Outputs stay read-only and are whatever is saved in the file.
• Rich or interactive outputs (widgets, JS-backed plots). Text, images, and HTML outputs only, with the same HTML sandboxing as other previews.
• Real-time collaboration with a running JupyterLab session.

Constraints we already know about

• Size: projects.readFile caps at 1 MB and returns truncated. Notebooks with embedded image outputs often exceed that, and truncated JSON can't be parsed or edited safely. These notebooks should open read-only with a clear message, or we need a decision on a higher cap for .ipynb.
• Conflicts: agents rewrite the whole file. Saves should use the same revision check the Files editor already uses, so a user edit never silently overwrites an agent's write, or the reverse.
• Performance: large notebooks need virtualized cell rendering (the file editor already virtualizes), and base64 outputs should only be decoded when visible.
• Surfaces: web and desktop first. Mobile could ship read-only (the [Feature]: Read-only `.ipynb` notebook preview #11033 preview) at first, with editing added later.

Possible follow-ups (not v1)

• Cell-aware diffs in the Diff panel and in turn checkpoints, instead of JSON line diffs.
• "Ask agent about this cell": reference a cell in the composer, similar to file mentions.

Questions for maintainers

1. Is cell-level source editing (no execution) a direction you'd accept, or should notebooks stay read-only in T3 Code?
2. For notebooks over the 1 MB read cap: read-only fallback, or a higher cap for .ipynb?
3. Should this wait for [Feature]: Read-only `.ipynb` notebook preview #11033 to land, or is one combined design preferred?