## 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.

```text
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