@wardby/cli 0.5.3 → 0.6.0

package/docs/coding-agent-setup.md

@@ -104,8 +104,8 @@ JOB_LAUNCHER=docker
   folder as missing. The machine needs git 2.24 or newer.
 - **Worker images.** Use worker images from the same release as the control
   plane. An older worker image rejects `local:` repositories (the run fails with
-  `worker_input_failed`), including a bring-your-own `workerImageRef` image,
-  which must be rebuilt on a current driver image.
+  `worker_input_failed`), including a Codex agent's bring-your-own
+  `workerImageRef` image, which must be rebuilt on a current driver image.
 
 ### What a coding run does
 
@@ -146,9 +146,9 @@ The server selects the image from `CODING_WORKER_IMAGE_NODE_PYTHON_3_12`
 at its committed root; see
 [Python projects](getting-started.md#python-projects).
 
-For any other language, point a Codex agent at your own image with
-`workerImageRef` ([Bring-your-own worker images](coding-worker-byo-images.md)).
-Claude Code agents cannot use a custom toolchain yet.
+For any other language, use `codingProfile.workerImageRef` (admin only). It is
+a custom image for the container that runs the agent's commands, for Codex and
+for Claude Code; see [Bring-your-own worker images](coding-worker-byo-images.md).
 
 ### Review agents
 
@@ -219,6 +219,8 @@ GITHUB_APP_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVA
 `npm run claude:images:local` builds the Claude agent image and both tool-runner
 images (`wardby-claude-tool-runner:phase5`, and
 `wardby-claude-tool-runner:phase5-node-python` for the `node-python` toolchain).
+It also builds `wardby-claude-tool-runner-custom:phase5`, a test-only custom
+tool runner that `npm run test:claude-docker` needs.
 This local, immutable-`sha256:` ID form of the `CODING_CLAUDE_*` images is only
 accepted by the Docker launcher.
 `JOB_LAUNCHER=kubernetes` needs both images pushed to a registry and set as
@@ -262,6 +264,112 @@ See [release verification](release-verification.md) for the complete gate.
 If the repository has `docs/knowledge/index.md`, every coding run's prompt
 includes it. See [Architecture knowledge bundles](knowledge.md).
 
+## Repository instructions
+
+Every coding run loads the repository's own instructions; there is no
+`codingProfile` setting to turn this off. Codex reads the repository's
+`AGENTS.md` itself, directly from the checkout. Claude Code is handed
+`CLAUDE.md`, `.claude/CLAUDE.md`, and whatever either file pulls in with
+`@path` imports, up to 5 import levels deep; a repository that only has
+`AGENTS.md` gets a one-line `CLAUDE.md` that imports it, so a repository
+written for another coding agent still has its instructions in Claude Code.
+Subdirectory `CLAUDE.md` files (anything other than the repository root and
+`.claude/CLAUDE.md`) are not loaded unless an imported file pulls them in.
+
+Claude Code's instructions and skills are read from the checkout and bounded:
+at most 64 KiB per file, 200 files, and 256 KiB combined; symlinks and
+non-UTF-8 files are refused. A file that doesn't pass, or that would push
+the run's input past its 512 KiB size limit once encoded (skills and the
+deepest imports are dropped first), is left out and logged as
+`coding.claude_context_skipped` (the first 50 individually, then one
+aggregate line with an overflow count); when the repository's context can't
+be read at all, the run continues without it and logs
+`coding.claude_context_unavailable`. A run never fails because its
+repository context couldn't be loaded.
+
+Claude Code never receives the repository's `.claude/settings.json`, hooks,
+`.mcp.json`, agents, or commands — only Markdown instruction files and
+`.claude/skills/<name>/SKILL.md` files pass the allowlist, whatever an
+instruction file imports. Repository instructions and skills are untrusted
+guidance: they can shape a run's work but never relax the worker's sandbox
+rules.
+
+## Claude Code loading mode
+
+`codingProfile.claudeBareMode` controls how Claude Code uses the repository
+instructions above. It defaults to `true` and only affects Claude Code
+agents.
+
+- **`true` (default, bare mode).** Claude Code keeps its hardened bare mode.
+  Wardby adds the repository's instruction files to the system prompt in
+  full, and lists each skill by name, description, and path; the model reads
+  a skill's full `SKILL.md` itself with `run_command`.
+- **`false`.** Bare mode is off. Claude Code loads `CLAUDE.md` and skills
+  itself, through its native Skill tool, instead of reading them from the
+  system prompt. Repository settings, hooks, MCP configuration, agents, and
+  commands are still never loaded in either mode; native loading also locks
+  Claude Code's own hooks to wardby's managed set.
+
+If the worker can't write the native-mode context to disk for a run, that
+run falls back to bare mode instead of failing, and the worker logs a
+`claude_context_unavailable` warning.
+
+The agent owner or an admin can change it:
+
+```json
+{ "id": "<agent-id>", "codingProfile": { "claudeBareMode": false } }
+```
+
+## Repository skills
+
+`codingProfile.repoSkills` loads the repository's own agent skills into a
+run. It defaults to `true`.
+
+| Builder     | Reads skills from                   | `repoSkills: true` (default)                        | `repoSkills: false`                |
+| ----------- | ----------------------------------- | --------------------------------------------------- | ---------------------------------- |
+| Codex       | `.agents/skills/`, `.codex/skills/` | Repository skills load                              | Every repository skill is disabled |
+| Claude Code | `.claude/skills/<name>/SKILL.md`    | Repository skills load (bare or native mode, above) | No skill context is collected      |
+
+Codex's own four built-in skills (`imagegen`, `openai-docs`, `skill-creator`,
+`skill-installer`) are always disabled, whatever `repoSkills` is set to —
+wardby's coding runs never offer them. With `repoSkills: false`, the Codex
+worker scans both roots for the skill names to disable; that scan stops after
+2000 directory entries, to bound the work an adversarial skills tree could
+cause, logs `codex_skill_scan_truncated`, and disables whatever names it found
+so far rather than failing the run.
+
+Claude Code skills ship to the worker as their `SKILL.md` only. A skill's
+other files (scripts, references, data) stay in the repository checkout and
+are read or run through the command runner at
+`/workspace/.claude/skills/<name>/`.
+
+Turn repository skills off for an agent:
+
+```json
+{ "id": "<agent-id>", "codingProfile": { "repoSkills": false } }
+```
+
+**Upgrading.** `repoSkills` and `claudeBareMode` both default to `true`, so
+upgrading changes behavior for existing agents: Claude Code agents start
+loading `CLAUDE.md` and `.claude/skills/` (previously neither was loaded),
+and Codex agents stop getting Codex's own built-in skills (previously always
+offered). Set `repoSkills: false` on an agent to keep its repository's
+skills out of its runs; there is no setting that keeps repository
+instructions themselves out, for either builder.
+
+Use the worker images (`CODING_WORKER_IMAGE` and `CODING_CLAUDE_WORKER_IMAGE`)
+from the same release as the control plane. On an older Claude Code worker
+image, runs fail with `worker_input_failed` once the repository has a
+`CLAUDE.md`, `AGENTS.md`, or skill to load, or the agent sets `repoSkills` or
+`claudeBareMode` to `false`; on an older Codex worker image, runs of agents with
+`repoSkills: false` fail the same way. A `workerImageRef` image must also be
+rebuilt for this release: on this release's driver image for a Codex agent, or
+on this release's tool runner image for a Claude Code agent. On a Claude Code
+agent, `workerImageRef` replaces only the tool runner (the container that runs
+the agent's commands); Claude Code itself always runs on
+`CODING_CLAUDE_WORKER_IMAGE`. See
+[Bring-Your-Own Coding-Worker Images](coding-worker-byo-images.md).
+
 ## Budgets
 
 A coding run's budget is reserved when it is dispatched: the agent's own

package/docs/coding-packages.md

@@ -42,8 +42,10 @@ request never names the internal proxy.
    image to build or maintain; the agent installs what it needs at run time.
 2. **A custom `workerImageRef` with dependencies baked in.** Still supported:
    point the agent's profile at your own image, built on wardby's driver base
-   image (see [Bring-your-own worker images](coding-worker-byo-images.md)),
-   with everything preinstalled. Setting `workerImageRef` needs `agents:admin`
+   image for a Codex agent, or `FROM` the same release's tool runner image for
+   a Claude Code agent (see
+   [Bring-your-own worker images](coding-worker-byo-images.md)), with
+   everything preinstalled. Setting `workerImageRef` needs `agents:admin`
    and the admin role, and the image must be pinned by digest.
 3. **Both together.** Use a custom image for a toolchain or system libraries
    the registry can't provide (a compiler, a non-Node/Python runtime, apt

package/docs/coding-services.md

@@ -194,7 +194,9 @@ to an agent that allows at least one service.
 
 A [bring-your-own worker image](coding-worker-byo-images.md) must be built on
 driver v11 or later to run with services; an agent whose `workerImageRef`
-predates driver v11 rejects the run input once services are on it.
+predates driver v11 rejects the run input once services are on it. For a
+Claude Code agent, build the custom image `FROM` the tool runner image of the
+same wardby release.
 
 ## Letting a coding agent change the declaration
 

package/docs/coding-worker-byo-images.md

@@ -7,6 +7,9 @@ wardby's published **driver base image** and point your agent's
 `workerImageRef` at it, instead of waiting for wardby to hand-author a new
 `Dockerfile.<toolchain>`.
 
+The driver image is for Codex agents. A Claude Code agent's image starts from a
+different base; see [Codex and Claude Code](#codex-and-claude-code).
+
 ## The driver image
 
 `ghcr.io/wardby/wardby/wardby-coding-worker-driver` contains wardby's
@@ -112,13 +115,188 @@ point one at an arbitrary image without the step-up scope. The scope alone
 isn't enough: the caller must also hold the admin role (see
 [roles and privileged operations](security-deployment.md#roles-and-privileged-operations)).
 
-## Codex only
+## Codex and Claude Code
+
+A Codex agent runs in one container, and its commands run there too. A Claude
+Code agent uses two containers: one runs Claude Code and holds its API key; the
+other runs the agent's commands and has your repository. `workerImageRef` always
+replaces the container that runs commands.
+
+|                                | Codex agent                                                       | Claude Code agent                                                                                               |
+| ------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| What `workerImageRef` replaces | the agent's only container                                        | the container that runs commands                                                                                |
+| Build your image `FROM`        | [the coding-worker driver image](#the-driver-image) (`driver-vN`) | the `wardby-claude-tool-runner` image from the same wardby release (or `wardby-claude-tool-runner-node-python`) |
+| Rebuild when                   | the driver image changes                                          | you upgrade wardby                                                                                              |
+| Claude Code itself runs on     | —                                                                 | wardby's standard image, never yours                                                                            |
+
+The driver image sections above are for Codex. The subsections below are for
+Claude Code. In them, "tool runner" means the container that runs a Claude Code
+agent's commands.
+
+### Build a custom image for a Claude Code agent
+
+1. **Find your release's tool runner image.** It is the value of
+   `CODING_CLAUDE_TOOL_RUNNER_IMAGE` on your server. To start from Node and
+   Python, use `CODING_CLAUDE_TOOL_RUNNER_IMAGE_NODE_PYTHON_3_12` instead. A
+   release value looks like
+   `ghcr.io/wardby/wardby/wardby-claude-tool-runner@sha256:<digest>`. If the
+   value is a local image ID (`sha256:...` only), give it a name first, because
+   Docker cannot build `FROM` a bare ID:
+   `docker tag sha256:<id> wardby-tool-runner-base:local`.
+2. **Make a build folder.** Use a small folder of your own, outside your
+   repository. Put in it the Dockerfile and only the files the Dockerfile
+   copies.
+3. **Write the Dockerfile.** Start from the image in step 1, install your tools
+   as `root`, then switch back to the tool runner's user:
+
+   ```dockerfile
+   FROM <image from step 1>
+   USER root
+   RUN apt-get update \
+       && apt-get install -y --no-install-recommends <your packages> \
+       && rm -rf /var/lib/apt/lists/*
+   USER 10001:10001
+   ```
+
+   Keep these rules:
+   - The last `USER` line is `USER 10001:10001`.
+   - Do not set `ENTRYPOINT` or `CMD`. The tool runner starts with the base
+     image's own entrypoint.
+   - Install everything at build time. A run cannot install system packages.
+   - Put tools in `/usr/local/bin` or `/usr/bin`. Do not put anything under
+     `/tmp` or `/home/wardby`: a run hides both.
+   - Put environment settings your commands need in a file under
+     `/etc/profile.d/` (see "How the tool runner runs commands" below). `ENV`
+     lines in the Dockerfile do not reach the agent's commands.
+
+4. **Build it:** `docker build --tag <name> <build folder>`. Release images are
+   `linux/amd64`. On an ARM machine, add `--platform linux/amd64` here and to
+   `docker run` in step 5.
+5. **Run the tests the way a run would.** Clone the repository to a throwaway
+   folder (on Linux, make it writable: `chmod -R a+rwX <clone>`). Then run the
+   project's test command with a run's restrictions and its fixed environment,
+   so `ENV` lines in the image do not apply:
+
+   ```sh
+   docker run --rm --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m --tmpfs /home/wardby:rw,noexec,nosuid,size=64m,uid=10001,gid=10001,mode=0700 --network none --user 10001:10001 --cap-drop ALL --security-opt no-new-privileges -v <clone>:/workspace -w /workspace --entrypoint env <name> -i HOME=/home/wardby LANG=C.UTF-8 PATH=/opt/wardby/bin:/usr/local/bin:/usr/bin:/bin sh -lc '<test command>'
+   ```
+
+   On an ARM machine, add `--platform linux/amd64` after `docker run`. Fix the
+   Dockerfile until the tests pass, then delete the clone.
+
+6. **Get an immutable reference.** A tag is refused.
+   - **Docker launcher** (wardby runs coding jobs with Docker on a single
+     machine): use the local image ID,
+     `docker image inspect --format '{{.Id}}' <name>`. Build on that machine.
+     Wardby never pulls these images.
+   - **Kubernetes:** push the image to a registry your cluster can pull from,
+     and use `<registry>/<name>@sha256:<digest>`.
+7. **Point the agent at it.** Call `update_agent` with the agent's id. This
+   needs the `agents:admin` scope and the admin role:
+
+   ```json
+   {
+     "id": "<agent id>",
+     "codingProfile": { "workerImageRef": "<reference from step 6>" }
+   }
+   ```
+
+8. **Try it.** Trigger a small task that uses your tools, such as "Run the
+   project's tests and report the results. Change nothing."
+
+To undo it, set `codingProfile.workerImageRef` to `null`. The agent then uses
+the standard tool runner for its `toolchain`.
+
+### Languages other than Node and Python
+
+A run can download packages only from wardby's package registry, which serves
+npm and PyPI. Packages for any other language must be in the image. If a
+package compiles native code, compile it in an earlier build stage and copy
+only the results into the final image. The final image then needs no compiler.
+
+The tool runner is based on Debian 12 (bookworm). Build stages that compile
+code must use a bookworm-based image too, so the results work with the tool
+runner's system libraries.
 
-`workerImageRef` applies to Codex agents. A Claude Code agent's commands run in
-the Claude tool runner, which `workerImageRef` does not change, so Claude Code
-agents cannot use a custom toolchain yet. They can use wardby's curated
-`node-python` toolchain (set the matching
-`CODING_CLAUDE_TOOL_RUNNER_IMAGE_NODE_PYTHON_3_12` image).
+This example adds Ruby and a project's gems. It is a starting point to adapt,
+not a tested recipe. Copy the project's `Gemfile` and `Gemfile.lock` into the
+build folder first.
+
+```dockerfile
+# Stage 1: install Ruby and the project's gems, compiling any native code.
+FROM ruby:3.3-slim-bookworm AS builder
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends build-essential \
+    && rm -rf /var/lib/apt/lists/*
+ENV BUNDLE_PATH=/usr/local/bundle \
+    BUNDLE_DEPLOYMENT=true
+WORKDIR /build
+COPY Gemfile Gemfile.lock ./
+RUN bundle install
+
+# Stage 2: the tool runner from your wardby release, plus Ruby and the gems.
+FROM <tool runner image from step 1>
+USER root
+# Shared libraries Ruby needs at run time, plus any library your native gems
+# link to (for example libpq5 for pg).
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends libffi8 libgmp10 libssl3 libyaml-0-2 zlib1g \
+    && rm -rf /var/lib/apt/lists/*
+# Ruby lives in /usr/local, and the gems in /usr/local/bundle.
+COPY --from=builder /usr/local /usr/local
+# Settings for the agent's commands (Dockerfile ENV lines do not reach them).
+RUN ldconfig \
+    && printf '%s\n' \
+      'export GEM_HOME=/usr/local/bundle' \
+      'export BUNDLE_PATH=/usr/local/bundle' \
+      'export BUNDLE_APP_CONFIG=/usr/local/bundle' \
+      'export BUNDLE_DEPLOYMENT=true' \
+      > /etc/profile.d/ruby.sh \
+    && sh -lc 'ruby --version && bundle --version'
+USER 10001:10001
+```
+
+Pin the `ruby` image by digest for repeatable builds. Rebuild the image when
+the project's `Gemfile.lock` changes.
+
+### If a run fails
+
+| What you see                            | What it usually means                                                                                                                                  |
+| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `worker_tool_runner_unreachable`        | The image was not built `FROM` the tool runner of the same wardby release, or the Dockerfile changed its `USER` or `ENTRYPOINT`.                       |
+| A command is "not found"                | The tool is not in the image, or a setting it needs is in an `ENV` line instead of `/etc/profile.d/`.                                                  |
+| "Permission denied" when running a file | On Docker, something writes a program to `/tmp` or `/home/wardby` and runs it. Point that tool's temporary or cache folder under `/workspace/.cache/`. |
+
+### How the tool runner runs commands
+
+These details explain the rules above.
+
+- **User and privileges.** Commands always run as user `10001`, with no Linux
+  capabilities and `no-new-privileges`. `root` and setuid programs do not work
+  at run time.
+- **Filesystem.** The root filesystem is read-only. `/tmp` and `/home/wardby`
+  are small, empty scratch space; anything the image put there is hidden. On
+  Docker, files there cannot be run. `/workspace` holds the repository; put
+  caches, build output and temporary files under `/workspace/.cache/`.
+- **Shell and environment.** Each command runs as `sh -lc "<command>"` with a
+  fixed environment: `HOME=/home/wardby`, `LANG=C.UTF-8`, `TMPDIR` under
+  `/workspace/.cache/`, wardby's package registry settings, and
+  `PATH=/opt/wardby/bin:/usr/local/bin:/usr/bin:/bin`. The login shell reads
+  `/etc/profile` and the files in `/etc/profile.d/`, so that is where your own
+  settings go. `/etc/profile` resets `PATH` to Debian's default, so add any
+  other folder to `PATH` in your `/etc/profile.d/` file.
+- **Network.** The tool runner reaches only wardby's package registry (npm and
+  PyPI).
+- **Images on the Docker launcher are never pulled.** When wardby runs coding
+  jobs with Docker on a single machine, the image must already be on that
+  machine. Kubernetes needs a registry digest
+  (`repo@sha256:<64 hex>`).
+- **Server settings.** Claude Code itself always runs on
+  `CODING_CLAUDE_WORKER_IMAGE`. The server still needs both
+  `CODING_CLAUDE_WORKER_IMAGE` and `CODING_CLAUDE_TOOL_RUNNER_IMAGE` set, even
+  for agents with their own `workerImageRef`.
+- **Toolchain.** While `workerImageRef` is set, `toolchain` and
+  `toolchainVersion` do not choose the image, for either builder.
 
 ## Running services with a BYO image
 
@@ -130,6 +308,20 @@ a worker built on an older driver base doesn't recognize the input's
 without them. Rebuild your image on a current `driver-vN` digest (see "The
 driver image" above) before allowing any service on an agent that uses it.
 
+## Repository skills need a current driver
+
+On a Codex agent, a `workerImageRef` image never receives Claude Code's
+repository context (`claudeContext`) or `claudeBareMode`. The one new input key
+it can see is `repoSkills`, which wardby writes only when an agent sets
+`repoSkills: false`. A worker built on
+an older driver base validates its input with a strict schema, so it rejects
+runs of agents with `repoSkills: false` (the run fails with
+`worker_input_failed`), and it keeps offering Codex's built-in skills
+(`imagegen`, `openai-docs`, `skill-creator`, `skill-installer`), which a
+current driver always disables. Rebuild any `workerImageRef` image on a
+current `driver-vN` digest (see "The driver image" above) before relying on
+either behavior.
+
 ## What this doesn't cover
 
 wardby does not re-validate the contents of your built image beyond the

package/docs/coding-worker-isolation.md

@@ -1,16 +1,24 @@
 # Coding Worker Isolation
 
-Wardby supports isolated Codex execution with Docker or Kubernetes and
-credential-separated Claude Code execution with Docker. Both launchers fail
-closed when the effective runtime does not match the reviewed policy.
+Wardby runs Codex and Claude Code coding workers through Docker or Kubernetes
+launchers. Both fail closed when the effective runtime does not match the
+reviewed policy. Claude Code separates its model-facing worker from its
+workspace-facing tool runner: Docker uses companion containers, while
+Kubernetes uses a native sidecar in the run pod.
 
 ## Security Boundary
 
-Coding-agent repositories and instructions are untrusted. The Docker daemon,
-host kernel, Wardby control plane, immutable worker image, and dedicated coding
-proxy are trusted. Containers are defense in depth rather than a VM boundary;
-production should run the Docker host on a dedicated worker node or VM with no
-production credentials beyond those required by the proxy.
+Coding-agent repositories and instructions are untrusted. The Wardby control
+plane, immutable worker images, dedicated coding proxy, and the platform
+enforcing container and network policies are trusted.
+
+### Docker launcher
+
+The Docker daemon and host kernel are trusted. Docker containers are defense
+in depth rather than a VM boundary. Production should run the Docker host on a
+dedicated worker node or VM with no production credentials beyond those
+required by the proxy. The Kubernetes launcher section below describes the
+corresponding pod and network rules.
 
 The Codex worker has one network attachment: a unique per-run internal bridge using
 Docker's isolated gateway mode. It has no default external route, published
@@ -588,6 +596,7 @@ Kubernetes-specific settings (`src/config/providers.ts`,
 | `KUBERNETES_CONTEXT`            | (unset → in-cluster/default kubeconfig context) | Which kubeconfig context `ClientNodeKubernetesApi` connects with.                                                                                                                                                                                                                                     |
 | `KUBERNETES_RUNTIME_CLASS`      | (unset)                                         | e.g. `gvisor` on GKE. Unset means pods run without a sandboxing runtime class — logged once per launch as `kubernetes_runtime_class_unset` and development-only.                                                                                                                                      |
 | `KUBERNETES_RESOURCE_QUOTA`     | (unset)                                         | Name of the namespace ResourceQuota run pods count against, e.g. `wardby-coding` in the GKE overlay. When set, a run whose pod would not fit the quota's free room waits in the coding queue instead of failing at pod create. Needs `get` on that one `resourcequotas` object. Unset means no check. |
+| `KUBERNETES_PLATFORM`           | `generic`                                       | `generic`, `gke-autopilot` or `eks`. Selects the cluster's admission rules that run pods are conformed to. `gke-autopilot` and `eks` both require `KUBERNETES_RUNTIME_CLASS=gvisor`; see the platform profile section below.                                                                          |
 | `KUBERNETES_RUN_PRIORITY_CLASS` | (unset)                                         | PriorityClass for run pods and the preflight canary, e.g. `wardby-coding-run` in the GKE overlay. Must be an existing class and a DNS-1123 subdomain; `system-` classes are refused. Unset means no class (priority 0).                                                                               |
 
 The `CODING_CPUS` / `CODING_MEMORY_MB` / `CODING_PIDS` / `CODING_DISK_MB` /
@@ -798,6 +807,16 @@ landed on — cannot appear in it. That case reached a live Autopilot launch wit
 every dry-run-derived check passing, and is now pinned by tests. Treat a
 captured fixture as a lower bound on what a platform mutates.
 
+The `eks` profile is for Amazon EKS clusters with a dedicated gVisor node group.
+EKS has no managed sandbox runtime, so the cluster must provide a RuntimeClass
+named `gvisor` with handler `runsc` whose `scheduling` block selects nodes
+labelled `wardby.dev/sandbox=gvisor` and tolerates the taint
+`sandbox=gvisor:NoSchedule` on those nodes. Kubernetes' RuntimeClass admission
+merges that block into each pod; Wardby sets neither the node selector nor the
+toleration itself, and the `eks` profile forgives exactly that nodeSelector and
+that toleration and nothing else. Pod resources follow the generic rules, plus
+an explicit ephemeral-storage request and limit.
+
 ### The enforcement gate
 
 The Kubernetes API can create a NetworkPolicy object without that policy
@@ -911,9 +930,9 @@ default 90,000ms):
 1. `platform` — pure configuration, checked before any cluster API call:
    `assertPlatformConfig` (`src/providers/jobs/kubernetes-platform.ts`) refuses
    a deployment that cannot work under `KUBERNETES_PLATFORM`. Under
-   `gke-autopilot` this means `KUBERNETES_RUNTIME_CLASS` must be `gvisor`
-   (gVisor is mandatory there — an unset or different runtime class is refused,
-   not warned about), and the effective `CODING_MAX_DISK_MB` must leave room
+   `gke-autopilot` and `eks`, `KUBERNETES_RUNTIME_CLASS` must be `gvisor` (an
+   unset or different runtime class is refused, not warned about). Under
+   `gke-autopilot` the effective `CODING_MAX_DISK_MB` must also leave room
    for the worker container's 1 GiB reservation inside Autopilot's 10 GiB pod
    ephemeral-storage ceiling. The same assertion runs again at process
    start-up in `buildConfiguredExecutor`
@@ -942,20 +961,55 @@ default 90,000ms):
 5. `canary` — creates a real run pod + NetworkPolicy from the same builders
    as a live run, running a script that waits for policy enforcement (as
    above) then attempts DNS resolution, a connect to the proxy's deny port,
-   the internet (`1.1.1.1:443`), the metadata server, and the proxy itself —
-   requiring every one of the first four to fail and the proxy connect to
+   the internet (`1.1.1.1:443`), the cloud metadata endpoints (`169.254.169.254:80`,
+   the EKS Pod Identity agent `169.254.170.23:80` and its IPv6 address
+   `[fd00:ec2::23]:80`, and EC2's IPv6 metadata address `[fd00:ec2::254]:80`), and the proxy itself —
+   requiring every one of the first four kinds to fail and the proxy connect to
    succeed. Any other outcome, or a canary pod that itself fails to
    schedule/run, is `kubernetes_isolation_unsupported:canary`.
 
 This whole preflight is **memoized per launcher instance and its failure is
 sticky**: `KubernetesJobLauncher.runPreflight()` caches the first call's
-promise (`this.preflightResult ??= ...`, `kubernetes.ts:472-487`), including
+promise (`this.preflightResult ??= ...`, `kubernetes.ts:790`), including
 a rejection — so once a launcher process has seen preflight fail, every
 subsequent `launch()` in that process fails immediately with the same error
 without re-probing the cluster. A fresh preflight requires a new process
 (or, from the CLI, a fresh `wardby coding preflight` invocation, which is
 not memoized).
 
+**A long-running server process starts this same memoized preflight at
+start-up, not on the first coding run.** `wardby serve`, `wardby mcp` (both
+transports), and `wardby scheduler` each call `KubernetesJobLauncher.warmUp()`
+right after the executor is built, fire-and-forget: it runs the identical
+preflight `launch()` would otherwise run lazily, so the first coding run
+after a restart doesn't pay the preflight's own cost (a canary pod, routinely
+tens of seconds on a resource-constrained cluster such as `kind`).
+`wardby scheduler` needs this just as much as the other two — it dispatches
+scheduled coding runs through its own Kubernetes executor without ever
+starting an MCP server, so without this it would still pay the lazy cost on
+its first scheduled run. The result is logged once at start-up — an info
+line on success, a warning naming the failure code (e.g.
+`kubernetes_isolation_unsupported:<check>`) otherwise.
+
+**A start-up warm-up's failure is logged and retried on the next run, not
+left stuck until restart.** This is the one way a preflight failure is
+_not_ memoized: a transient cluster problem at process start (the API
+server briefly unreachable, a slow CNI not yet programmed, and the like)
+must not fail every coding run for the rest of that process's life, so a
+failed warm-up clears its own failed attempt once it has logged it, and the
+_next_ `launch()` runs the preflight fresh — succeeding if the cluster has
+since recovered. A `launch()` that was already waiting on that same
+in-flight warm-up attempt still fails with that attempt's error (it shares
+the same preflight call), exactly as it always has; it's only the attempt
+_after_ that one which retries. A preflight failure `launch()` triggers
+itself — because no warm-up ran, or because a warm-up's cleared failure was
+never retried before the next `launch()` found the cluster still broken —
+keeps the original behavior exactly: it stays memoized, failing every
+subsequent `launch()` in that process until it is restarted. This never
+runs for a one-shot CLI command (`wardby run`, `wardby coding preflight`,
+migrations, imports) — only for a process that stays up to serve or
+dispatch runs.
+
 **A hung pod create during preflight can leave a preflight pod and its
 NetworkPolicy behind.** If `createPod` never settles (rather than failing),
 the preflight's own timeout still fires and the caller sees `:timeout`, but