## TL;DR
A container built without a kernel spec (or with a spec pointing at a build-time path) fails at kernel launch with 'kernel error' and no useful message. Bake the spec into the image: install ipykernel in the image's python, run `python -m ipykernel install --prefix=/usr/local --name [env]` during the build, and verify the spec's argv is an absolute path that exists in the final image. Test kernel launch inside the built container before shipping.

```text
agent failed to set the kernel spec in the scheduled container, kernel error
```

## Use this when
- Kernel launch fails inside a scheduled container with an empty error.
- The container was built without ipykernel or without a spec install.
- It works outside the container.

## Not for this skill when
- The kernel launches but the notebook fails. That is a notebook or env bug.
- The container itself does not start. That is an image problem.

## Steps
1. Inspect the image: run it and check `jupyter kernelspec list`. Verify: the expected spec exists.
2. Read the spec's kernel.json argv. Verify: the python path is absolute and exists in the image.
3. Fix the Dockerfile: install ipykernel and install the spec with `--prefix` during build. Verify: the build log shows the install.
4. Launch a kernel inside the container: `python -m ipykernel_launcher -f /tmp/t.json`. Verify: it stays alive.
5. Run the scheduled command in the container. Verify: end-to-end success.

## Variant phrasings
### container kernel spec missing
Short form. Bake the spec into the image.

### docker jupyter kernel error
The symptom phrasing. Check the spec argv.

### kernelspec absolute path container
The fix phrasing. Absolute paths survive the build.

Compatibility: Docker/OCI containers, ipykernel 6.x. The bake-during-build rule is universal.

## Why it happens
Kernel specs are installed per-python and per-prefix, and container builds that pip-install ipykernel but never run the spec install leave the image with the package but no registered kernel. Worse, a spec installed at build time with a relative or build-only path breaks in the final image. The kernel launch then fails with the classic empty error because the process cannot even start.

## Edge cases / pitfalls
- Multi-stage builds can drop the spec if it was installed in the builder stage. Install in the final stage.
- `--user` installs go to a home dir that may not exist or differ at runtime. Use `--prefix` or `--sys-prefix` deliberately.
- The runtime user must be able to read the spec files. Check permissions in the final image.
- Test as the runtime user, not root. Root's paths and permissions differ.

## Provenance

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