docker/agent.Dockerfile: DeepSeek (dsh) plugin install fails on a fresh build (pnpm not found)

[timkjr]

What happened

Building the agent base image from a clean checkout (node scripts/build-agent-image.mjs --no-cache) fails at the DeepSeek Harness step:

#12 0.505 dsh: initialized profile dsh-tui at /home/agent/.dsh/profiles/dsh-tui
#12 0.508 dsh: pnpm not found on PATH — install pnpm to manage profile plugins
ERROR: process "... dsh plugin --profile dsh-tui add @deepseek-harness-tui/dsh-tui ..." did not complete successfully: exit code: 127

Where

docker/agent.Dockerfile, the RUN ... dsh plugin --profile dsh-tui add @deepseek-harness-tui/dsh-tui ... step in the agent user-setup layer.

Repro

node scripts/build-agent-image.mjs --no-cache

on a fresh checkout of master (no local branch changes).

Cause (best guess, not confirmed)

dsh's plugin installer appears to now require pnpm on PATH to manage profile plugins, and the base node:22-bookworm-slim image doesn't have it installed. This is presumably a behavior change in a recent @deepseek-ai/dsh release, since the Dockerfile step itself is unchanged.

Impact

Docker cases (the whole agent base image) can't currently be built from scratch on a fresh checkout, blocking Docker-mode session support entirely until fixed.

Suggested fix

Add pnpm to the base image (either via corepack enable — already bundled with Node 22 — or npm install -g pnpm) before the dsh plugin install step.

---

Found incidentally while verifying Docker support for the OMP integration PR.

[Ark0N]

Fixed on master: #350 by @opticon454, plus a follow-up in d5b5f8f.

Your guess was right on the mechanism. dsh plugin does not bundle a package manager; it spawnSyncs a literal pnpm with no npm fallback, so the ENOENT surfaces as that exit 127. The image now installs pnpm in the same layer as dsh and proves it with pnpm --version. I went with npm install -g pnpm rather than corepack enable: corepack fetches the shimmed version lazily on first use, so the version that actually built the profile would not appear in the build log.

Two things came out of it beyond the missing binary:

• pnpm, unlike npm, refuses dependency lifecycle scripts by default and fails the install over it (ERR_PNPM_IGNORED_BUILDS, exit 1, measured on pnpm 11.24). The tui's dependency tree is resolved by dist-tag, so which packages that hits changes between rebuilds: the tree you and fix(docker): install pnpm for DeepSeek profile #350 hit pulled @google/genai, today's does not. The profile step therefore passes --config.dangerouslyAllowAllBuilds=true, which is the same exposure the image already accepts three layers up, where npm install -g runs the install scripts of every transitive dep of the five CLIs above it with no gate at all.
• The image smoke test in docs/docker-cases.md could not have caught this. dsh --version answers a different question than the other CLIs in that loop, since dsh is a launcher and a working binary says nothing about whether a profile exists. The doc now checks the profile too, and the loop knows about dsh and omp.

Verified with a full --no-cache build: all nine CLIs report versions, and the dsh-tui profile launches and paints under an arbitrary runtime uid.