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

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.

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