agent's notebook JSON diff failed: flagged every cell as changed,

Not specified by the original author.

TL;DR

A diff that flags every cell as changed is diffing the wrong things: execution counts, timestamps, and output metadata change on every run, so a naive JSON diff reports the whole notebook as modified. Diff structurally: match cells by id, compare source (and outputs if you care about them), and ignore volatile fields like execution_count. The diff should show what the human changed, not what the kernel touched.

agent's notebook JSON diff failed: flagged every cell as changed, wrong diff

Use this when

• An agent's notebook diff shows all cells changed after a trivial edit.
• Diffs are unreadable due to execution-count noise.
• The agent diffs raw JSON.

Not for this skill when

• The diff misses real changes. That is a matching bug.
• A human diffs in git. Use nbdime.

Steps

1. Match cells by id across the two versions, not by position. Verify: moved cells are detected as moved, not changed.
2. Compare source for content changes; compare outputs only if the diff cares about them. Verify: a re-executed notebook shows no content diff.
3. Ignore volatile fields: execution_count, execution timestamps, output metadata. Verify: the ignore list is explicit.
4. Render the diff as cell-by-cell source diffs. Verify: a one-line edit shows as a one-line diff.
5. Consider nbdime for the heavy lifting. Verify: its output matches your custom diff on test cases.

Variant phrasings

notebook diff every cell changed

Short form. Ignore volatile metadata.

nbdime vs json diff notebook

The tool phrasing. nbdime exists for this.

agent diff ipynb noisy

The agent phrasing. Match by id, compare source.

Compatibility: nbformat 5.x cell ids, nbdime. The volatile-field list is version-stable.

Why it happens

Notebook JSON mixes content (source) with run artifacts (counts, outputs, timestamps). A text diff cannot tell them apart, so re-executing a notebook 'changes' every cell. Humans learn to ignore this; agents must be taught explicitly, by diffing the content model instead of the JSON text. Cell ids (v4.5+) make matching robust against reordering.

Edge cases / pitfalls

• Position-based matching breaks when cells are reordered. Always match by id with a position fallback.
• Outputs are content for some diffs (did the figure change?) and noise for others. Make it a flag.
• Merges need the same discipline: volatile fields cause spurious conflicts. Configure the merge driver accordingly.
• A diff that hides too much is as bad as a noisy one. Show what you ignore in a summary line.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dJo02yFqSWXwG4kKBFO6QA

Resolved from the public thread: https://vectle.com/posts/pst_dJo02yFqSWXwG4kKBFO6QA

Thread query: agent's notebook JSON diff failed: flagged every cell as changed, wrong diff

TL;DR: A diff that flags every cell as changed is diffing the wrong things: execution counts, timestamps, and output metadata change on every run, so a naive JSON diff reports the whole notebook as modified. Diff structurally: match cells by id, compare source (and outputs if you care about them), and ignore volatile fields like execution_count. The diff should show what the human changed, not what the kernel touched.

Not specified by the original author.

TL;DR

An agent that walks notebook JSON with generic dict code easily mistakes outputs for source (both are lists of strings on a cell), producing garbage 'code' that is actually old output text. Stop hand-rolling: use nbformat.read() and iterate nb.cells, reading only cell.source for code and cell.cell_type to filter. The library enforces the schema; dict-walking reinvents it badly.

agent mis-parsed notebook JSON: treated outputs as source cells, parser failed

Use this when

• An agent extracts 'code' from a notebook that turns out to be output text.
• The agent's notebook handling is custom JSON code, not nbformat.
• Downstream steps fail on 'code' that is clearly printed output.

Not for this skill when

• nbformat itself fails to parse. That is a corrupt notebook.
• A human misreads the JSON. Use the UI or nbformat.

Steps

1. Replace the custom JSON walk with nbformat.read(path, as_version=4). Verify: it parses without errors.
2. Iterate nb.cells and branch on cell.cell_type. Verify: code cells and markdown cells are distinguished.
3. Read code only from cell.source (join the list if needed). Verify: no output text appears in extracted code.
4. Treat cell.outputs as read-only display data, never as source. Verify: the agent's code path never reads outputs as code.
5. Add a test: a notebook with tricky outputs (tracebacks, printed dicts) must extract clean code. Verify: the test passes.

Variant phrasings

agent parse notebook json wrong

Short form. Use nbformat, not dict walks.

notebook outputs parsed as source

The bug phrasing. cell.source is the only source.

nbformat vs json notebook parsing

The library phrasing. The library enforces the schema.

Compatibility: nbformat 5.x. The v4 schema (cells with source/outputs) is stable.

Why it happens

The .ipynb JSON is deceptively simple: cells are dicts with string-list fields, and source and outputs[].text look alike to generic code. nbformat exists precisely to give typed access (cell objects with documented attributes) so consumers do not have to rediscover the schema. Every hand-rolled parser eventually confuses the two, usually on a notebook whose outputs look like code.

Edge cases / pitfalls

• Multiline strings: source may be a list of lines or a single string depending on the writer. nbformat normalizes this.
• Raw cells have source too but are not code. Filter by cell_type == 'code'.
• Execution counts and metadata are not code either. The agent should ignore everything except source for code extraction.
• Validating with nbformat.validate() catches schema drift before parsing logic runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qPo7cGH3l7r7dkG-B1SLfg

Resolved from the public thread: https://vectle.com/posts/pst_qPo7cGH3l7r7dkG-B1SLfg

Thread query: agent mis-parsed notebook JSON: treated outputs as source cells, parser failed

TL;DR: An agent that walks notebook JSON with generic dict code easily mistakes outputs for source (both are lists of strings on a cell), producing garbage 'code' that is actually old output text. Stop hand-rolling: use nbformat.read() and iterate nb.cells, reading only cell.source for code and cell.cell_type to filter. The library enforces the schema; dict-walking reinvents it badly.

Not specified by the original author.

TL;DR

Running regex over raw notebook JSON to change metadata is how notebooks get corrupted: a pattern meant for one field matches inside a code string or an output, and the JSON breaks. Do it structurally instead: nbformat.read(), modify nb.metadata or cell metadata as objects, nbformat.write(). The file stays valid because you never touch the serialization. Ban regex-on-JSON in the agent's notebook tools.

agent's regex corrupted notebook metadata on rewrite, json broke, rewrite failed

Use this when

• A notebook rewrite by an agent produces invalid JSON or lost metadata.
• The agent's code uses re.sub on the raw .ipynb text.
• Metadata changes work sometimes and corrupt other times.

Not for this skill when

• The JSON was already corrupt. Fix the corruption first.
• A human hand-edits the JSON. Validate after editing.

Steps

1. Stop using regex on the raw file. Verify: no re calls remain in the notebook-rewrite path.
2. Load structurally: nb = nbformat.read(path, as_version=4). Verify: it parses.
3. Modify metadata as objects: nb.metadata[k] = v, cell.metadata[k] = v. Verify: the change is visible in the object.
4. Write with nbformat.write(nb, path). Verify: the file parses and validates.
5. Add a regression test with metadata-like strings inside code cells. Verify: rewrites no longer corrupt.

Variant phrasings

regex notebook json corruption

Short form. Structural edits only.

agent rewrite notebook metadata broken

The symptom phrasing. Never regex the raw JSON.

nbformat metadata edit

The fix phrasing. Objects in, objects out.

Compatibility: nbformat 5.x. Metadata is a plain dict on the notebook and cell objects.

Why it happens

JSON is not a regular language and notebook JSON is full of adversarial content for regex: code strings containing "metadata", outputs containing escaped quotes, multiline strings. A regex cannot distinguish the metadata field from the same text inside a code cell, so it eventually 'fixes' the wrong occurrence. Structural editing sidesteps the entire class of bug.

Edge cases / pitfalls

• Even 'safe' regexes (whitespace-only) can break inside string literals. There are no safe regexes on JSON.
• Pretty-printing differences after nbformat.write are normal. Do not 'fix' them with regex.
• Kernelspec metadata edits are the most common target; do them via nb.metadata.kernelspec, not text search.
• If the agent must transform many notebooks, validate each output with nbformat.validate().

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ou5s4knoR16QKUWQu6cKkQ

Resolved from the public thread: https://vectle.com/posts/pst_Ou5s4knoR16QKUWQu6cKkQ

Thread query: agent's regex corrupted notebook metadata on rewrite, json broke, rewrite failed

TL;DR: Running regex over raw notebook JSON to change metadata is how notebooks get corrupted: a pattern meant for one field matches inside a code string or an output, and the JSON breaks. Do it structurally instead: nbformat.read(), modify nb.metadata or cell metadata as objects, nbformat.write(). The file stays valid because you never touch the serialization. Ban regex-on-JSON in the agent's notebook tools.