What happens when you commit a Jupyter notebook full of chart images, huge dataframes, and cell execution counts that mean nothing to anyone else? Your repository balloons, your diffs become unreadable, and your reviewer quietly gives up. That is the problem nbstripout was built to solve. But in 2027, a new question sits on top of it: does that same workflow behave the same way in Cursor as it does in VS Code?
The short answer is that it mostly does, because Cursor is a fork of VS Code and inherits much of its extension ecosystem. The longer answer is where the interesting work lives. Git filters, notebook formats, and editor-specific notebook handling all interact in ways that surprise teams. This article walks through those interactions, the workflow differences that matter, and the practical setup that actually holds up. (Notebook interface)
Why notebooks and Git were never a natural pair
A Jupyter notebook is a JSON file. It stores code cells, markdown cells, and, crucially, the outputs of every cell that has been run. That includes base64-encoded images, printed dataframes, error tracebacks, and an execution count for each cell. The file format itself is defined in the notebook format specification, which is worth skimming once so you understand what is actually being versioned.
The consequence is that two people running the same notebook produce different files. Cell outputs differ. Execution counts differ. A one-line code change can produce a diff with thousands of lines of image data. Git was designed for text, and notebooks are text files pretending to be documents.
There are two broad strategies for handling this. The first is to strip outputs before they ever reach the repository. The second is to keep them and rely on smarter diffing tools. Most mature teams land on the first, with the second as a supplement.
What nbstripout actually does
nbstripout is a small Python utility that removes notebook outputs and execution counts. It is typically installed as a Git clean filter, which means it runs automatically when you stage a file. You configure it once per repository, and from then on every `git add` of a `.ipynb` file passes through the filter before the content is stored.
The mechanism is worth understanding because it explains most of the weird behaviour people hit later. Git supports clean and smudge filters through its attributes system, documented in the Git attributes reference. A clean filter transforms content on the way into the repository. A smudge filter transforms it on the way out. nbstripout installs itself as a clean filter and leaves the smudge side alone, which is why your working copy keeps its outputs while the committed version does not.
That asymmetry is the source of the first common mistake. People install nbstripout, commit, and then panic because their local notebook still shows outputs. It is supposed to. The filter only affects what Git stores.
The second common mistake is assuming the filter is global. It is not, unless you explicitly configure it that way. Each clone needs the filter registered, which means either every developer runs the install command or the repository ships a setup step. Teams that skip this end up with a mix of stripped and unstripped commits, which is worse than either approach alone.
The nbconvert alternative
There is a second path: clearing outputs at conversion time using nbconvert, which offers preprocessors that can strip outputs during export. The difference is timing. nbstripout works at commit time and is invisible to the author. nbconvert works when you explicitly run a conversion, so it depends on someone remembering. For repository hygiene, the filter approach wins because it does not rely on discipline.
Where Cursor and VS Code start to diverge
Cursor is built on the VS Code codebase, so the editor surface looks familiar. Extensions largely carry over. The Jupyter extension that powers notebook editing in VS Code is documented in Microsoft’s official guide to Jupyter notebooks in VS Code, and much of that behaviour transfers. (Do cursor alternatives work inside ai code editor race) (Jupyter documentation overview)
But “mostly transfers” is doing a lot of work in that sentence. The differences that matter for notebook workflows fall into a few categories.
| Area | VS Code | Cursor |
|---|---|---|
| Notebook editing | Native Jupyter extension support | Inherited, generally functional |
| Git filter execution | Runs in the terminal, editor-agnostic | Same, runs in the terminal |
| AI-assisted edits | Limited, via extensions | Core feature, applied to cells |
| Diff review | Standard notebook diff view | Same view, plus AI edit previews |
| Extension compatibility | Reference implementation | Broad but not guaranteed |
The key insight is the second row. Git filters do not care which editor you use. They run in Git, not in the editor. So nbstripout behaves identically whether you open the repository in VS Code, Cursor, or a plain terminal. Anyone who tells you Cursor breaks nbstripout is probably describing a different problem, usually a missing filter registration in a fresh clone.
Where Cursor genuinely changes the workflow is in how notebooks get edited. AI-assisted cell rewriting produces larger, faster changes than hand-editing. That makes the quality of your diffs more important, not less. A tool that rewrites six cells at once is a tool that benefits enormously from stripped outputs, because otherwise the reviewer cannot see the code change through the noise. If you are weighing editors on this axis, the comparison of Cursor against Windsurf is a useful starting point for how each handles multi-cell edits. (Cursor alternatives setup guide configure vs code windsurf)
The AI edit problem
There is a subtler issue. AI assistants sometimes regenerate a cell’s output as part of an edit, or re-run cells to verify their changes. In a repository with nbstripout installed, that is harmless at commit time. In a repository without it, an AI assistant can inflate a notebook by megabytes in a single interaction.
This is why teams adopting AI editors should treat output stripping as a prerequisite, not an optimisation. The practical sequence is: install the filter first, then turn on the AI features. Doing it in the other order means your first week of AI-assisted work produces a commit history nobody wants to review.
Setting up nbstripout so it survives real teams
The setup itself is short. The failure modes are in the edges.
- Install the package in the project environment rather than only globally, so the filter resolves the same way for everyone.
- Run the install command inside the repository to register the clean filter in the local Git config.
- Commit a `.gitattributes` file that maps `*.ipynb` to the filter, so the mapping travels with the repository.
- Document the per-clone install step in the README, because the filter registration does not travel.
- Verify by staging a notebook with outputs and checking that the staged version is clean.
Step three is the one people skip, and it is the one that makes the setup portable. Without the attributes file, the filter registration exists only on the machine where it was run. With it, every clone knows which files should be filtered, and the only remaining per-clone step is registering the filter command itself.
Step five is worth doing literally. Stage a notebook, then inspect the staged content rather than the working copy. If outputs are still present in the staged version, the filter is not running, and the usual cause is a path mismatch between the installed executable and what Git is trying to call.
A note on partial stripping
Not every team wants everything removed. Some want to keep execution counts for reproducibility, or keep specific output types. nbstripout supports configuration for this, but every exception you add is a decision someone has to remember. The pragmatic default is to strip everything and store any genuinely important output as a separate artefact, such as an exported report or a saved figure. Notebooks are for code and narrative; outputs are for the run, not the repository.
The diff review workflow
Once outputs are stripped, notebook diffs become readable. Code changes appear as code changes. Markdown changes appear as markdown changes. Reviewers can actually review.
This is where the editor choice starts to matter again, but in an indirect way. Cursor’s AI features generate more edits per session, so the review step carries more weight. Teams that pair aggressive AI editing with stripped outputs get a workable loop. Teams that pair it with unstripped notebooks get a review process that collapses under its own weight.
If you are evaluating editors primarily on how they handle AI-driven changes to existing code, the breakdown of how AI edits actually modify your files is worth reading before you commit to a workflow. The mechanics of patch versus rewrite matter more for notebooks than for ordinary source files, because a rewrite can silently discard cell structure.
What to check before standardising on either editor
Before rolling either editor out across a team, verify a small set of things in a real repository with real notebooks.
- Does the notebook diff view render correctly for your largest notebook?
- Does the Git filter run when you stage from the editor’s built-in source control panel as well as from the terminal?
- Do AI-assisted edits preserve cell boundaries and metadata?
- Does a fresh clone of the repository produce clean commits after the documented setup steps?
That last one catches the most problems. A repository that works on the original author’s machine and fails on a fresh clone is a repository with an undocumented dependency. Notebook tooling is unusually prone to this because the filter registration lives outside version control.
For teams still choosing an editor, a structured evaluation checklist helps avoid deciding on vibes. The same discipline applies to notebooks: test the actual workflow, not the demo.
Conclusion
The honest summary is that nbstripout works the same in Cursor and VS Code, because it runs in Git rather than in the editor. The differences that matter are downstream: Cursor’s AI features generate more edits, which raises the value of clean diffs, which makes output stripping more important rather than less. Get the filter installed and documented first. Then choose your editor, and test the workflow on a fresh clone before you trust it. The teams that struggle with notebooks in 2027 will mostly be the ones that treated repository hygiene as an afterthought and then blamed the editor.
FAQ
Does nbstripout work in Cursor?
Yes. nbstripout installs as a Git clean filter, and Git runs independently of whichever editor you use. Cursor, VS Code, and a plain terminal all invoke the same filter. If stripping appears to fail in Cursor, the cause is almost always a missing filter registration in that clone, not an incompatibility with the editor.
Why do my notebook outputs still appear after installing nbstripout?
Because the filter only affects what Git stores, not your working copy. Your local notebook keeps its outputs by design. To confirm the filter is working, stage the notebook and inspect the staged version rather than the file on disk.
Is nbstripout better than clearing outputs with nbconvert?
For repository hygiene, generally yes. nbstripout runs automatically at commit time, so it does not depend on anyone remembering to run a conversion. nbconvert is useful when you control the export pipeline, but it is a manual step in most local workflows.
Do I need to install nbstripout in every clone of the repository?
Yes, for the filter registration. The `.gitattributes` file travels with the repository and tells Git which files to filter, but the command that performs the filtering must be registered locally. Document the install step in your README so new contributors do not skip it.
Does using an AI editor make notebook repositories messier?
It can. AI assistants sometimes re-run cells or regenerate outputs while editing, which inflates notebooks quickly. Installing nbstripout before enabling AI features keeps that inflation out of your commit history. The order of operations matters more than the editor choice.
Will stripping outputs break reproducibility?
It removes the record of what a previous run produced, not the ability to reproduce it. If specific outputs matter, export them as separate artefacts such as reports or saved figures. Keeping them inside the notebook makes diffs unreadable and does not guarantee they match the current code anyway.
