## TL;DR
nbgrader hashes every locked cell at assignment creation, and autograde fails the whole submission when a submitted locked cell no longer matches. First determine whether the student edited a locked cell (their problem) or the instructor regenerated the assignment after release (your problem). If the student edited it, restore the locked cell from the release version; if you regenerated, re-release the assignment and have students fetch the update before resubmitting.

```text
nbgrader autograde failed: checksum mismatch on a locked cell
```

## Use this when
- `nbgrader autograde` reports a checksum mismatch naming a specific locked cell.
- Submissions that were fine last term now fail after the assignment notebook was edited and re-released.
- A single student's submission fails the checksum while others pass.

## Not for this skill when
- Autograde runs but hidden tests fail on a correct-looking solution. That is a test or solution bug, not a checksum problem.
- `nbgrader validate` raises on re-run with the traceback hidden. That is the validate path, a different fix.

## Steps
1. Identify the offending cell: the autograde output names the cell id and shows the expected vs actual checksum. Expected: you know exactly which cell mismatches.
2. Compare the submitted locked cell against the release version: `nbgrader` stores the release copy; diff the cell source. Expected: you can see whether the change is a student edit or an instructor-side regeneration.
3. If the student edited a locked cell, restore that cell's source from the release notebook and keep their solution cells intact. Expected: the restored cell matches the release checksum.
4. Re-run `nbgrader autograde` on the repaired submission. Expected: the checksum error is gone and grading proceeds to the tests.
5. If YOU regenerated the assignment after release, re-run the full generate step and release the new version, then have affected students update and resubmit. Expected: new submissions checksum against the new release version.
6. Prevent recurrence: tell students to fetch assignment updates before starting work, and avoid editing released notebooks except through a new release. Expected: no further mismatches from version drift.

## Tool compatibility
nbgrader 0.9.x; Jupyter notebook 6.x/7.x; Python 3.9 through 3.11.

## Variant phrasings
### nbgrader checksum mismatch locked cell
The short phrasing. Diff the submitted cell against the release copy to find who changed it.

### autograde failed: cell checksum does not match
The alternate wording of the same error. Same restore-or-rerelease decision.

### nbgrader locked cell modified by student
The student-edit framing. Restore the locked cell from the release version.

## Why it happens
nbgrader's integrity model is simple: locked cells (instructions, test scaffolding) are hashed when the instructor runs the generate step, and autograde recomputes those hashes on every submission. Any byte-level difference, even trailing whitespace, breaks the match. This catches students tampering with tests, but it also fires when the instructor edits the assignment and re-releases without students updating, because now the student's copy was built from the old release. The fix is therefore a provenance question first and a file operation second: restore the cell if the student changed it, or re-release if you did.

## Edge cases / pitfalls
- Restoring the locked cell from the wrong release version just moves the mismatch. Always diff against the exact release the student fetched.
- Students who edit in plain Jupyter instead of the nbgrader assignment view can accidentally alter locked cells. Point them at the correct workflow.
- Re-releasing mid-deadline without telling students creates a wave of mismatches. Announce the new release and the update command together.
- Checksum covers cell source and some metadata. Reformatting tools run over the notebook can flip the hash without changing visible content.

## Provenance

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