[Codex Desktop] First-class Jupyter notebook (.ipynb) editing, execution, and rich output support

What variant of Codex are you using?

Codex Desktop App on macOS (26.908.40834, Apple Silicon).

What feature would you like to see?

I would like Codex Desktop to support Jupyter notebooks (.ipynb) as a first-class interactive workspace surface, rather than treating them primarily as JSON files that an agent may patch indirectly.

The goal is not merely "Codex can modify an .ipynb file." The desired experience is closer to a lightweight VS Code/Jupyter workflow integrated directly into Codex Desktop:

workspace file tree
    -> open .ipynb
    -> edit code/markdown cells
    -> choose kernel/environment
    -> run cell / run all
    -> inspect stdout, traceback, plots, tables, HTML, LaTeX, etc.
    -> select a cell/output and ask Codex about it
    -> let Codex make cell-aware edits
    -> immediately review/run the result

This is particularly important for research, machine learning, data analysis, visualization, and remote GPU workflows, where notebooks are often the primary development artifact rather than a secondary export format.

Current limitation

Codex Desktop has made substantial progress toward becoming an agent-native development workspace: it now has a workspace file tree, built-in text/code editing surfaces, terminal execution, artifact previews, browser integration, and remote/SSH workflows.

However, opening and working with .ipynb files still lacks a native notebook experience. In practice, users still need VS Code, JupyterLab, or another notebook frontend for routine notebook editing and execution.

This creates an awkward split in workflows such as ML research:

1. Ask Codex to inspect or modify an experiment.
2. Switch to VS Code/Jupyter to inspect the notebook structure and outputs.
3. Run cells manually there.
4. Inspect plots/tables/errors.
5. Return to Codex with the result or describe which cell needs changing.

The rest of the Codex workspace increasingly reduces this context switching, but notebooks remain a major gap.

Desired notebook UI

When a user opens an .ipynb file from the workspace file tree, Codex Desktop should open a notebook-native editor rather than raw JSON.

At minimum it should support:

• Code cells and Markdown cells.
• Edit cell contents directly.
• Add/delete/move cells.
• Cell execution count and execution state.
• Run Cell.
• Run All.
• Run Above / Run Below, if practical.
• Interrupt execution.
• Restart kernel.
• Clear output.
• Save/revert with normal dirty-state handling.
• Reliable synchronization when the file is changed by Codex or externally.

Kernel / environment support

The notebook should be backed by a real Jupyter-compatible kernel/runtime.

Users should be able to select or resolve an environment such as:

• system Python;
• venv / .venv;
• Conda;
• project/container Python;
• remote SSH Python environment;
• potentially other registered Jupyter kernels.

For an SSH remote workspace, the notebook kernel should run on the remote host, alongside the project's files and dependencies. A Mac client connected to a Linux GPU server should not require manually starting JupyterLab, exposing a port, copying the notebook locally, or setting up an SSH tunnel just to run cells.

Rich output support

Notebook outputs should render inline using standard Jupyter MIME representations where possible, including:

• text/plain;
• stdout/stderr;
• Python tracebacks;
• image/png, image/jpeg, SVG;
• Matplotlib figures;
• HTML;
• LaTeX/math;
• DataFrames/tables;
• JSON and other structured outputs.

Outputs should remain inspectable after execution and should be usable as context for the active Codex thread.

Cell-aware Codex integration

The most important opportunity is to make notebooks agent-native, not merely to reproduce JupyterLab.

Useful interactions would include:

• Select a code or Markdown cell -> Add to Codex Thread.
• Select one or more cells -> Ask Codex / Edit with Codex.
• Select a traceback -> ask Codex to diagnose it.
• Select a plot/table/output -> ask Codex to explain or modify the generating cell.
• Preserve notebook path + stable cell identity in the context payload.
• Allow Codex to propose/apply changes at the cell level, rather than rewriting large regions of notebook JSON.
• Show notebook cell changes in the normal review/diff workflow in a human-readable way.

For example:

@experiments/ablation.ipynb :: cell 12

would be much more useful context than exposing the serialized JSON representation of the same notebook.

Unsaved-state correctness

Codex should operate on the current notebook document state, including unsaved cell edits, rather than only the last version persisted to disk.

This is important because stale notebook state is already a known failure mode in the IDE integration (#20182): Codex can modify the saved .ipynb while the user has newer unsaved notebook changes, forcing the user to choose which version to lose.

A native Desktop notebook surface should have one authoritative in-memory notebook document model shared between user edits and agent edits.

Why this seems feasible within the current Codex architecture

This request does not appear to require inventing notebook support entirely from scratch. Existing Codex-related workflows already expose several pieces of the required stack:

• Codex has notebook-oriented skills/workflows for creating and editing .ipynb files.
• Reports from Codex Desktop show a jupyter_notebook MCP with notebook execution actions such as notebook_execute_hidden (#43175).
• nteract-based MCP workflows can already attach to a Python notebook and execute cells; #29483 is specifically about rendering an image/png result after execution, rather than execution itself.
• Google Colab MCP exposes notebook CRUD/execution concepts such as get_cells, add_code_cell, update_cell, and run_code_cell; #23441 tracks Codex-side dynamic tool exposure issues.
• The VS Code extension already has notebook-adjacent integration work, but selected notebook cells still cannot reliably be added to a Codex thread (#38514).

So the underlying building blocks for notebook structure, execution, and structured output appear to exist in different layers already. The main request is to integrate them into one first-class Codex Desktop experience.

Relationship to the broader Codex Desktop workspace

This also fits the broader direction of Codex Desktop becoming a place where the user and agent work around the same artifacts rather than constantly leaving for an external IDE.

Related workspace requests include:

• #20950 — repository tree as an in-app context-selection tool.
• #29125 — robust remote artifact/video/PDF preview.
• #20164 — file-tree path actions and refresh behavior.

Notebook support is one of the remaining cases where even a user who is otherwise comfortable working almost entirely inside Codex still needs to keep VS Code/Jupyter open.

Related notebook issues

These appear related but narrower rather than duplicates of this umbrella request:

• #6543 — teach Codex to use nbformat / edit notebooks without mangling JSON.
• #19656 — allow plugins to reference code inside .ipynb cells.
• #20182 — stale saved-file edits when a notebook has unsaved changes.
• #23441 — Colab MCP notebook tools do not dynamically appear in Codex Desktop.
• #29483 — nteract notebook image output does not render correctly in Codex MCP Apps.
• #34903 — notebook MCP resources load but notebook tools are not injected in the IDE extension.
• #38514 — selected Jupyter cell code cannot be added to the current Codex thread.
• #43175 — evidence of local jupyter_notebook MCP execution in Codex Desktop.

I could not find an existing issue whose scope is the complete native Codex Desktop notebook editor + kernel + rich-output + cell-aware agent workflow described here.

Suggested MVP / acceptance criteria

A reasonable first version would be complete enough if:

1. Double-clicking an .ipynb in the Codex Desktop file tree opens a notebook-native view rather than raw JSON.
2. Users can edit/add/delete/reorder Code and Markdown cells.
3. Users can choose a Python kernel/environment and execute individual cells or the complete notebook.
4. Standard text, traceback, image, HTML, LaTeX, and table outputs render inline.
5. Selecting a cell can add that cell to the active Codex thread with notebook path and cell identity.
6. Codex edits are structural/cell-aware and appear immediately in the open notebook.
7. Codex sees the latest in-memory notebook state and does not overwrite newer unsaved edits.
8. The same workflow works in SSH remote workspaces, with execution happening on the remote host.
9. Users do not need to manually install/configure a notebook-specific MCP server merely to open and run a normal .ipynb file.

The implementation could reuse Jupyter protocol components, notebook MCP infrastructure, nteract, or other existing components. The important part is the user-facing abstraction: .ipynb should be a first-class editable and executable artifact in Codex Desktop.

Start by reading the suggested MVP and acceptance criteria, then inspect the existing jupyter_notebook MCP execution actions and nteract-based workflows referenced in the issue, along with related issues #20182, #29483, and #38514. Done means an integrated Codex Desktop notebook surface supports cell editing, kernel execution, rich outputs, cell-aware Codex context, unsaved-state safety, and remote SSH execution without manual notebook MCP setup.