Uninstall DeepSeek Harness in containers: DSH plugin cache

Uninstalling DeepSeek Harness in containers is inherently more involved than on a host, because the default is "program follows the container, data stays on the volume." Deleting the container clears only the writable layer; the volume still holds profiles, installed DSH plugin records, sessions and credentials. And even after deleting both container and volume, image layers and build cache still occupy disk — three independent things, and many people stop after the first. State your goal first: delete container plus volume plus image and build cache for a complete removal, or delete only the container to keep data.

How DeepSeek Harness container uninstall differs from the host

Bottom line: a host uninstall is "remove program plus decide on data." A container uninstall adds image layers.

Option A: drop and rebuild (cleanest)

Bottom line: do not clean, rebuild. Delete the container and the volumes you no longer need, then start fresh from the image.

1. Decide whether data must be kept — this drives the next steps:

docker volume ls | grep dsh        # list DeepSeek Harness related volumes
# expected: your data volume names; delete them below if you do not want them

2. Stop and remove the container:

docker rm -f dsh

3. Remove the volume if appropriate — this is what actually makes data disappear:

docker volume rm dsh-data        # data volume: deleting it removes sessions and plugin records

4. Rebuild as before (see installing DeepSeek Harness in Docker).
5. Verify: check dsh plugin in the new container. Empty means the data really is gone; present means the volume survived.

Option B: targeted in-container cleanup (keep the container)

Bottom line: when keeping the container, clean plugins, then caches, then indexes. Never touch configuration or credentials.

1. Record the list first in case you need to restore:

dsh plugin          # note what is installed before removing

2. Remove plugins with the uninstall or remove subcommand (confirm with dsh plugin --help).
3. Clear caches and indexes — rebuildable data only, never the whole data directory.
4. Confirm the effect:

du -sh "$DSH_HOME"/* 2>/dev/null | sort -h | tail -5
# expected: the largest subdirectories shrink after cleanup

5. Verify: reinstall one plugin and run it once to confirm the environment still works.

Option C: slim the DeepSeek Harness image at build time

Bottom line: image size can only be reduced at build time. Files deleted at runtime are already in a layer and do not shrink the image.

1. Multi-stage builds: install and compile in a build stage; copy only artifacts into the runtime stage.
2. Install, use and clean in one layer: combine those into a single RUN so caches never persist in an intermediate layer.
3. Pick a smaller base image — but remember that slim and Alpine images often fail with native-module plugins (see the Docker install guide).
4. Prune build cache — frequently forgotten:

docker builder prune
# expected: reclaims build cache space; confirm no build is in progress

5. Verify: compare docker images sizes and run the functionality once to confirm nothing needed was removed.

Handling three DeepSeek Harness volumes

Bottom line: the data volume decides whether sessions survive, the workspace volume decides whether your files survive, and the cache volume is safe to delete.

1. Name volumes by purpose (dsh-data, proj-data, dsh-cache) so cleanup cannot delete the wrong one.
2. List before cleaning and confirm ownership of each volume.
3. Back up rather than delete: back up the data volume first (see DeepSeek Harness on disk).

Three CI cleanup steps for DeepSeek Harness

Bottom line: CI cleanliness comes from no persistent volume, temporary containers, and explicit cache clearing. The first matters most.

1. Point the data directory inside the container (no volume mount), so data vanishes with the container.
2. Run temporary containers (--rm) to avoid accumulating stopped containers.
3. Clear local caches and temp directories at the end of the job.

docker run --rm -e DSH_HOME=/tmp/dsh -v "$PWD:/workspace" dsh-local:0.2.0-rc.2 dsh --version
# expected: the container is destroyed on exit, leaving no trace under /tmp/dsh

4. Verify: check volume lists and disk usage on the runner after a run to confirm nothing accumulates.

DSH plugin troubleshooting for container cleanup

Bottom line: decide what you deleted — container, volume and image layer are three things. No single action produces all three effects.

1. Data still there — the volume remains; deleting containers does not delete volumes.
2. Disk not freed — images and build cache remain; neither is reclaimed by container or volume deletion.
3. Data lost by mistake — check whether you deleted the data or workspace volume; restore from backup or start over.
4. CI growing over time — either the data directory is on a persistent volume or build cache is never pruned.
5. Plugins still present after reinstalling — the data volume was preserved. Sometimes that is desired; confirm your goal.
6. Repair status, stated honestly: this follows Docker's container, volume and layer semantics plus the official CLI data directory notes. Containerized DeepSeek Harness has no dedicated official guide, so confirm volume and cache names against your own layout.

For host-side (non-container) uninstall and residue cleanup, see dsh uninstall and data cleanup.

Sources: apps/cli/README.md, Docker Docs · volumes, Docker Docs · build cache.