notebook not trusted: javascript outputs blocked after a git checkout

TL;DR

Git rewrites file bytes on checkout (line endings, filters), which invalidates the SHA signature in the notebook trust database, so the notebook opens untrusted and JavaScript outputs are blocked. Re-run jupyter trust notebook.ipynb on the checked-out file to sign the current bytes. If the same notebook untrusts itself after every checkout, a git filter or line-ending conversion is changing bytes on the way in, and that is what needs fixing.

notebook not trusted: javascript outputs blocked after a git checkout

Use this when

• A notebook that was trusted shows 'Not Trusted' after git checkout or git pull, and widget or HTML outputs are blocked.
• JavaScript outputs render for colleagues but not for you after cloning or switching branches.
• Trust is lost repeatedly on the same repository across checkouts.

Not for this skill when

• jupyter trust reports success but outputs stay blocked. That is a moved or unreadable signature database, a different fix.
• You do not recognize the notebook's origin. Do not blindly trust it; inspect it first, per the shared-folder XSS skill.

Steps

1. Confirm the trust state: open the notebook and check the Trusted/Not Trusted indicator, or run jupyter trust --show notebook.ipynb. Expected: the notebook is listed as not trusted.
2. Check what changed on disk: git status and git diff --stat for the notebook. Expected: you see whether checkout modified the file bytes (line endings or smudge filters are the usual culprits).
3. Re-trust the current bytes: jupyter trust notebook.ipynb. Expected: output confirms the notebook is now trusted.
4. Reload the notebook in the browser and interact with a JavaScript output. Expected: widgets and HTML outputs render instead of showing the blocked placeholder.
5. If trust is lost after every checkout, inspect .gitattributes for filters and check core.autocrlf settings. Expected: you find the byte-changing setting; normalize it so checkout is byte-stable.
6. For a lasting fix, have the agent run jupyter trust as part of the post-checkout step in its workspace setup, after verifying the repository is the expected one. Expected: fresh checkouts are trusted without manual clicks.

Tool compatibility

nbformat 5.x signing; notebook 6.x/7.x and JupyterLab 3.x/4.x trust indicators; git 2.x.

Variant phrasings

jupyter notebook not trusted after git pull

The pull phrasing of the same byte-change problem. Re-trust the checked-out file.

not trusted badge after cloning notebook repo

The clone phrasing. Trust is per-machine; every fresh clone starts untrusted.

javascript output blocked notebook git checkout

The symptom phrasing. The block is the trust system doing its job on changed bytes.

Why it happens

Notebook trust is a signature database keyed by the SHA hash of the exact file bytes, kept per user. Any byte-level change, including invisible ones like CRLF versus LF line endings or git smudge filters, produces a different hash, so the previously trusted signature no longer matches and the notebook correctly opens untrusted. This is the trust system working as designed: it cannot tell a benign line-ending change from a malicious output edit. Re-trusting signs the new bytes, and stabilizing the checkout bytes stops the cycle.

Edge cases / pitfalls

• Re-trusting a notebook you did not author and have not inspected signs whatever outputs it contains. Trust is a security decision, not a rendering fix.
• .gitattributes text normalization (CRLF on Windows checkouts) is the most common repeat offender. Decide on one line-ending policy for the repo.
• Agents that git checkout inside automation should re-trust only notebooks from the expected repository, never arbitrary files dropped into the workspace.
• The signature database is per user and per machine. Trusting on your laptop does not trust the notebook on the shared server.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H2v34MYsHCp31jNBS4-eWA