## TL;DR
Quarto picks a kernel from document metadata, project config, or defaults, and when the agent's environment has several kernels the render can silently execute with the wrong one, baking stale or wrong-environment outputs into the document. Set the kernel explicitly with the `jupyter` front-matter key (or `--execute` with the right kernel) and re-render. Then confirm the executed kernel by checking an output that only the right environment could produce, like a package version print.

```text
agent's quarto render failed: executed with the wrong kernel, outputs stale
```

## Use this when
- A Quarto render completes but outputs reflect an old environment (wrong package versions, missing data).
- The rendered document's outputs do not match what the notebook shows interactively.
- An agent renders in CI and the outputs differ from the developer's local render.

## Not for this skill when
- Quarto fails to find a template or filter. That is a Quarto installation or project config problem.
- A cell raises during the render. That is a code bug, surfaced correctly by the right kernel.

## Steps
1. Inspect what kernel Quarto used: check the render log and the document front matter for a `jupyter:` kernel key. Expected: you can name the kernel that executed the document.
2. List available kernels in the render environment: `jupyter kernelspec list`. Expected: you see both the wrong kernel that was picked and the right one that should have been.
3. Pin the kernel explicitly in the document front matter under the `jupyter` key with the intended kernel name. Expected: the front matter names the kernel unambiguously.
4. Delete previously rendered outputs (the `_freeze` directory or output files) so stale results cannot survive. Expected: no cached outputs remain to be mistaken for fresh ones.
5. Re-render with cache disabled for the verification run. Expected: the render log shows execution against the pinned kernel.
6. Verify with a canary: include a cell that prints the interpreter path and a key package version, and read it in the rendered output. Expected: the canary matches the intended environment, proving the right kernel executed.

## Tool compatibility
Quarto 1.4.x and 1.5.x; Jupyter kernels via jupyter_client; nbclient-backed execution.

## Variant phrasings
### quarto render wrong kernel
The direct phrasing. Pin the kernel in front matter and clear frozen outputs.

### quarto executed with different kernel than notebook
The mismatch phrasing. The notebook's UI kernel and Quarto's render kernel are chosen independently.

### quarto outputs stale after render
The stale-output phrasing. Delete frozen outputs and re-render with the pinned kernel.

## Why it happens
Quarto's execution kernel resolution has several inputs: the document's `jupyter` front matter, project-level defaults, and finally the default kernel, and the notebook's own kernel metadata is only one of them. In agent-driven CI environments the kernel list often differs from the developer's laptop (a `python3` that means different environments in each place), so the render quietly picks whatever matches first. Frozen outputs then cement the mistake: the next render reuses the stale results without executing at all. Explicit pinning plus a canary cell turns a silent wrong-environment render into a loud, verifiable one.

## Edge cases / pitfalls
- Freezing is per project configuration. A `_quarto.yml` freeze setting can reintroduce stale outputs after you cleared them manually.
- The kernel name that is correct on the laptop may not exist in CI. Pin by a name that the CI image actually installs.
- Canary cells that print versions are documentation, not tests. For real gating, assert the version in the cell and let the render fail loudly.
- Agents that render on every commit should treat kernel resolution as part of the build: log the resolved kernel name in CI output.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aRVM-T0MGPOVfsLMRwknMg