devcontainer-kit v1.0.1

Interface stays 2. Patch: coding-agents-kit v1.0.1 so @default stays its own
account inside containers, and a doctor warning when a shared codex@default would
mix host and container Codex versions on the same state DB.

Changed

• Pins: coding-agents-kit v1.0.1 (AGENTKIT_TAG; tag commit 3f51881, tarball
  sha256 923277aa…, SHA256SUMS sha256 de17573e…). @default is the container's
  own account: the login profile no longer points CLAUDE_CONFIG_DIR / CODEX_HOME
  at [agents] default_profile (that made @default the named profile). A bare
  ak <cli> still follows AGENTKIT_DEFAULT_PROFILE_<CLI> when that is set.
  ak usage lists @default, and ak <cli> @default — and a plain claude /
  codex — uses the container's own home. Claude's @default is its own
  directory on the claude volume (~/.claude).

Added

• dck doctor: when [agents] host_profiles shares codex@default (the host's
  live ~/.codex, read-write inside), a warning (text and --json, schema-additive
  host_profiles.codex_versions) if the host's codex --version differs from the
  container's. A mismatched pair has corrupted that state DB; use a named profile
  inside (ak codex @name) or align the versions.

Fixed

• Herdr: a changed [herdr] label renames the machine again. dck ran
  herdr machine rename --label <label> <id>, the order Herdr 0.9.3's --help
  prints but its parser rejects (usage: herdr machine rename <profile-id> --label <label>); the failure stopped the rest of dck up (the machine id pushed inside,
  the mesh refresh, the layout). dck now passes the id first.
• Herdr: dck herdr add|status|repair and dck up no longer report a stopped
  remote server as answering. herdr status server exits 0 and prints
  status: not running while no server runs; dck now requires its
  status: running line.
• Herdr: dck up (and rebuild, start, restart) waits for the container's
  Herdr server before creating the standard layout, up to DCK_HERDR_LAYOUT_WAIT
  seconds (default 60) and only while the host's Herdr runs; when it does not start
  in time the layout is skipped with a note (run dck herdr layout) instead of
  failing with "the Herdr layout could not be created".
• dev.sh: the plain-compose fallback (no dck installed) chooses
  DCK_HOST_SSH_AUTH_SOCK by Docker provider before up and rebuild, as dck does:
  /dev/null on a provider without Docker Desktop's agent socket (colima, podman, …),
  so the agent bind no longer fails the start there. A bare docker compose up on
  such a provider still needs DCK_HOST_SSH_AUTH_SOCK=/dev/null (documented in the
  rendered compose file and docs/config.md).

Install

git clone --branch v1.0.1 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v1.0.1 (digests in the images workflow run).

devcontainer-kit v1.0.0

The first stable release. Interface stays 2; nothing breaks from v0.3.7, so upgrade with
dck init and dck rebuild so the image carries the new pins.

Stability commitment

From 1.0.0 the public interface follows semver: a breaking change to it needs a new major
version (and, for the files below, a new interface number). The public interface is:

• The dck verbs and flags: init, setup, up, down, stop, start, restart,
  ps, logs, shell, exec, build, rebuild, config, ports, ssh, herdr,
  host, agents, ask, doctor, --skill, help, --version, their documented flags
  (--repo, --profile, --project, --trust, --compose-file, --service, …) and the
  exit codes (0 ok, 1 failed, 2 usage, 3 configuration, 4 environment, 5 refused).
• The schemas: dck.toml and the host profile (docs/schema/dck-config-v2.json,
  dck-profile-v2.json) and the dck doctor --json report (dck-doctor-v2.json).
• The render contract: the files dck init writes and owns (devcontainer.json keys,
  compose, docker/local/<service>/, dev.sh), the dck:managed markers and user blocks it
  preserves, and the environment the entrypoint reads.

Internals (lib/, the layer installers, the image's build steps) are not part of it.

Changed

• Pins: herdr-peers v1.0.0 (HERDR_PEERS_TAG, verified by the sha256 of its
  SHA256SUMS, 11634ef2…; tag commit 3bf118d, 16 files), its first stable release
  (protocol 1).
• Pins: coding-agents-kit v1.0.0 (AGENTKIT_TAG; tag commit 57b82fa, tarball
  sha256 1fd86b4f…, SHA256SUMS sha256 8995e737…), its first stable release; the
  layer's install call (install.sh --no-rc) and its three skills are unchanged.
• Pins: deepworkplan-vim v1.0.0 (DWP_VIM_TAG; tag commit f0929f9, install.sh
  sha256 d1aaa207…, the value its SHA256SUMS and install.sh.sha256 publish), its first
  stable release: visible selections, OSC 52 copy without a clipboard tool, no stray start
  screen row.

Fixed

• A flaky editor layer no longer fails the image build. The deepworkplan-vim installer
  runs with --strict, and one plugin clone that lost a race with the network (seen as
  missing: nvim-cmp, or lualine.nvim / nvim-tree.lua away from the lockfile) failed the
  whole build. editor.sh now reruns the installer when --strict reports a plugin problem —
  up to 3 attempts, with a growing pause — and then fails the build, loudly; any other
  installer failure (a checksum, a refusal) still fails at once. The images scope runs the
  retry against a stub installer: one or two flaky attempts recover, three fail, and a
  non-plugin failure is never retried.
• Docs: every user doc, AGENTS.md, SECURITY.md, CONTRIBUTING.md and the dck skill
  re-verified against the code (init's base image and marker refusal, the App layout, doctor's
  problem list, satellites, PRIMARY mode, presets, dev_sh, node_first, per-developer CLIs);
  the README opens with a theme-aware logo (assets/).

Install

git clone --branch v1.0.0 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v1.0.0 (digests in the images workflow run).

devcontainer-kit v0.3.7

Interface stays 2. Upgrade with dck init and dck rebuild so the image carries the new
herdr-peers.

Changed

• Pins: herdr-peers v0.3.2 (HERDR_PEERS_TAG, verified by the sha256 of its
  SHA256SUMS, 8a8112ee…; tag commit da167c5, 16 files): agents inside a container get
  notices, plan lead records (lead, status --pane, lead show --pane) and DWP_PLAN
  ids, which DeepWorkPlan 7.7.1 lanes rely on. The image build checks every file its SHA256SUMS
  lists (now also bin/ and docs/schema/); the image and dck's host copy
  (dck host peers install) still install only the skill, every file of it listed.
• Pins: coding-agents-kit v0.7.1 (AGENTKIT_TAG; tag commit 0e3e3c6, tarball
  sha256 5a6e5380…, SHA256SUMS sha256 ccf0919e…): ak status, a named profile's
  suffixed API-key variable counts as its login, Gemini API keys listed under Antigravity,
  and the Antigravity launch warning only where the Google login is machine-wide.
• The repository's own container is re-rendered at v0.3.7, and the images scope now fails
  when docker/local/app/dck/ differs from its sources (images/versions.env,
  images/common/, lib/entrypoint.sh, lib/layers/) or from VERSION; the docker scope
  checks that herdr-peers --version inside both fixtures is the pinned tag.

Install

git clone --branch v0.3.7 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.7 (digests in the images workflow run).

devcontainer-kit v0.3.6

Interface stays 2.

Added

• Two modes for the coding-agent CLIs. The default: the CLIs chosen at onboarding
  ([agents] clis) are wired (home volume, DCK_AGENTS persistence, host-profile sharing,
  default_profile) and installed for everyone; a developer may install fewer. The
  advanced opt-in, [agents] supported = "all" | [...], wires every supported CLI,
  installed or not, and each developer chooses what to install; dck init offers it
  (one interactive question for a new dck.toml with the agents layer, or
  dck init --supported all|"a b"). What your image installs: env
  DCK_AGENT_CLIS > DCK_AGENT_CLIS in docker/local/.env > host profile [agents] clis
  (replace), then clis_extra (add) > dck.toml clis ([] = none), plus every
  INSTALL_<CLI>_CLI that is exactly true (environment or docker/local/.env). An
  unknown or unwired name stops dck up / rebuild (exit 3) with the list (in the default
  mode, with the way to the advanced mode); the layer refuses it at build time too
  (DCK_AGENT_SUPPORTED). See
  docs/config.md.
• The rendered compose passes DCK_AGENT_CLIS: "${DCK_AGENT_CLIS:-<clis>}" and one
  INSTALL_<CLI>_CLI: "${INSTALL_<CLI>_CLI:-false}" per wired CLI as build args, so
  plain compose and the editor's rebuild read docker/local/.env too; dck init creates
  a create-only docker/local/.env.example that explains the repository's mode and its
  options.
  dck up / rebuild pass the effective list, through a fourth runtime overlay
  (<project>-clis.yml, the build arg only) when it differs from dck.toml's.
• The image records what it installed (/opt/dck/agent-clis): dck up warns and dck doctor reports rebuild needed: dck rebuild when it differs from the requested list;
  the doctor shows the mode, supported, requested (with its source) and installed
  (layers.clis_mode, clis_supported, clis_effective, clis_source, clis_image).
• PRIMARY mode. dck [--project P] --compose-file F… <verb> without --service runs
  the main service through other compose files (a repository's own overlay, for example a
  preview proxy's backend file): the files replace dockerComposeFile in order, dck's
  runtime overlays still go last, with the same alias, label and Herdr machine as a plain
  up and every host step (always the compose backend). For up, rebuild, down,
  ps, logs, shell, exec, ssh, stop, start, restart, config, herdr,
  doctor (which lists the files in use: repo.compose_files, compose_override).
• antigravity as a coding-agent CLI kind ([agents] clis, supported, the host
  profile's clis / clis_extra, DCK_AGENT_CLIS, INSTALL_ANTIGRAVITY_CLI): the agents
  layer installs the Antigravity CLI (agy) through ak install antigravity, and the
  entrypoint persists ~/.gemini on an antigravity volume. Inside a container agy
  reaches no OS keyring, so it keeps each Google login in a file under that home —
  one login per ak profile (ak antigravity @name), several accounts side by side,
  which the macOS Keychain's single slot never allowed. Its profiles stay unshareable
  from the host ([agents] host_profiles skips them, as before). A state volume can no
  longer be named antigravity (it is the CLI's home volume).

Changed

• An existing repository keeps its wiring (the default mode: its clis); its compose
  file gains the build args, so dck up and dck doctor report it as stale until
  dck init re-renders it.
• [agents] host_profiles shares the ak profiles of the wired CLIs that exist on the host
  (in the advanced mode, every supported CLI, installed or not); what it skips is reported
  for the requested CLIs only.
• --service needs --project; --compose-file without --service is PRIMARY mode
  (it was a usage error).
• Agent tooling: the vendored deepworkplan skill moves to v7.6.3 and the AI Diff Reviewer
  skill to v3.3.11, the pack's pin (skills-lock.json, AGENTS.md provenance), through the
  pack's own upgrade flow and addon planner; .dwp/config.json now also records the dev
  container addon (the repository's own dck container, v0.3.5).
• Pins: coding-agents-kit v0.7.0 (AGENTKIT_TAG; tag commit d2b5b59, tarball
  sha256 8bd2746b…, SHA256SUMS sha256 c30da1be…): the antigravity kind, ak usage
  for Antigravity, and ak's capacity and lease commands.

Fixed

• With [agents] host_profiles on, an ak profile created inside for a CLI the host does not
  share (antigravity, cursor, or a CLI with no host profile) was written to
  ~/.dck/host/agentkit/profiles/<cli>/ in the container layer, so dck rebuild (or any
  recreate) lost it and its login. The entrypoint now links that directory to the CLI's
  directory on the agentkit volume (0700) — the one ak uses with the option off. Before
  a recreate, dck up --recreate and dck rebuild run that step inside the old container,
  so an older image's layer-only profiles move onto the volume first, without overwriting
  the volume's copy (the rest is kept on the volume as .<cli>.dck-pre-volume-<UTC>,
  logged by path). Shared CLIs' directories (the host's mounts) and anything on another
  device are never moved; a link pointing outside the volume is refused. See
  docs/layers.md.
• The preflight checked devcontainer.json's compose files even when --compose-file
  (PRIMARY mode, satellites) replaced them, so a given file with privileged, the Docker
  socket, host mounts or a path outside the repository started without --trust. It now
  checks the files compose runs.
• dck up reused an image dck did not build when one already had the service's tag (a
  pre-dck image left by a repository's old tooling, with its own entrypoint), so no host
  step ran until dck rebuild. dck up now inspects the image first: one without dck's
  DCK_IMAGE_VERSION or dck-entrypoint, or built by another dck version than the
  repository's render (docker/local/<svc>/dck/VERSION), is rebuilt and its container
  replaced, with a note naming the image and why.
• dck down left the primary's Herdr machine registered (only a satellite's down
  removed it). It now removes the machine and SSH alias dck up registered whenever the
  dev service goes down; the next dck up registers them again.

Install

git clone --branch v0.3.6 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.6 (digests in the images workflow run).

devcontainer-kit v0.3.5

Interface stays 2.

Added

• Workspace satellites through dck. dck --project P --compose-file F… --service S up|down|ps|logs|shell|exec|ssh|… acts on one service of another compose project — a
  second instance of a dev service (<svc>satellite) with its own project, files and
  ports — with every host step the main service gets: the authorized dck key, [ssh] copy_keys, host-profile overlays and default_profile, the git identity,
  HERDR_PEERS_SELF, its own Herdr machine (alias dck-<project>-<service>, label
  <project> · <service> or --label) with the mesh, and the Codex/Claude container
  config. Its sshd port is read from compose. down removes only that service, its Herdr
  machine and its SSH alias; the main service is never touched.
• up --seed-state-from VOLUME (satellites) copies only the login state (config_gh,
  config_dailybot; never history, keys or Herdr state) from another state volume into
  the satellite's, once, while it is empty.
• A recipe for repositories that start satellites from their own scripts
  (docs/shared-stack.md).

Fixed

• A workspace under the renamed user's home builds. With user other than dev
  and a workspace inside that user's home (user = "node", workspace = "/home/node/app"), the base block ran WORKDIR <workspace> before renaming the
  uid-1000 user: WORKDIR created /home/node first and usermod -m failed (exit 12).
  The rename and home move now come before WORKDIR, and such a workspace is created
  owned by the user. Every flavour; a repository without a renamed user renders as
  before.

Install

git clone --branch v0.3.5 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.5 (digests in the images workflow run).

devcontainer-kit v0.3.4

Interface stays 2.

Changed

• Pins: coding-agents-kit v0.5.3 (AGENTKIT_TAG; tag commit 5124f93, tarball
  sha256 f0903bf6…, SHA256SUMS sha256 0ab8e810…): Codex launched with --no-daemon
  when the app-server daemon is missing.

• Panes Herdr restores no longer land on a login screen. Herdr's session restore
  relaunches a plain claude --resume <id> or codex resume, without ak. With
  [agents] default_profile set (and shared), the container's login profile now exports
  CLAUDE_CONFIG_DIR / CODEX_HOME as that profile's home, so a plain CLI uses the
  default account; a value already set (ak's own) wins. dck doctor shows it.

• Codex skips its startup update check and the app-server daemon's auto-start inside
  containers. The entrypoint (dck_codex_config) writes check_for_update_on_startup = false and [features] daemon_auto_start = false into the container's own Codex
  configs (~/.codex on its volume, ak codex profiles on the container's
  volume) at every start, since dck pins every CLI version. Never in the host's Codex
  home or a host-shared profile; a value the developer set is kept. Codex's hooks are
  not pre-trusted: that consent stays the developer's.

• dev.sh surfaces dck's refusals (exit 5: a container configuration that reaches the
  host and needs --trust, or markers to fix) on stdout too, so a caller that discards
  stderr still sees why up, build or rebuild stopped.

Install

git clone --branch v0.3.4 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.4 (digests in the images workflow run).

devcontainer-kit v0.3.3

Interface stays 2. Additive: a repository that sets none of the new keys renders
byte-identically to v0.3.2.

Added

• HERDR_PEERS_SELF inside containers. Asks from a Codex pane failed with "no reply
  route" until HERDR_PEERS_SELF named the container's machine id in the host's Herdr
  catalog. dck up, dck herdr add (after every registration) and dck herdr mesh now
  record that id on the state volume (new entrypoint function dck_herdr_self) and the
  login profile exports it; dck herdr remove clears it. dck doctor shows both ids
  (herdr self; herdr.id / herdr.self_inside in --json) and flags a mismatch.
• Shared compose stacks (docs/shared-stack.md), all additive:
  a repository that sets none of these renders byte-identically to v0.3.2.
  • The user block: # >>> user:<svc> >>> … # <<< user:<svc> <<< inside the dck
    service, kept verbatim. Plain keys for what dck does not render (depends_on,
    healthcheck, …); x-dck-merge: for keys it does, merged at dck init (lists
    appended, maps merged with the user's entry winning, scalars and replace-only keys
    such as command and entrypoint replaced in any YAML form). A plain key dck also
    renders is refused with the fix.
  • Top-level user:volumes / user:networks sub-blocks and [compose] volumes, so
    the file's other services (a database, workers) declare their data volumes and
    networks with their exact names and existing volumes keep reattaching; a name
    declared twice is refused.
  • Port strings: ssh_port and ports accept compose expressions
    ("${DJANGO_RUNSERVER_HOST_PORT:-8000}:8000", "5001:3000"), loopback-prefixed
    unless they name a host IP; the launcher resolves ${VAR:-default} (environment,
    then docker/local/.env) for dck ssh, Herdr and the doctor.
  • [build] context (build from the repository root; dck's COPY paths follow it) and
    [build] dockerfile (a Dockerfile shared by several services, where dck's blocks and
    its dck/ directory go).
  • [compose] project and [compose] networks (one top-level networks:, external).
  • [agents] node_first = true: the agents' own Node first on PATH (Dockerfile
    ENV and login shells), for a repository whose tooling needs it; off by default.
  • dev_sh = false (dck init --no-dev-sh): a repository that keeps its own dev.sh;
    dck init neither creates nor touches it.
  • [agents] presets: the ak alias presets (classic, providers). Unset keeps both,
    as before; new renders write presets = [] (off).
• [agents] default_profile (host profile): { claude = "@work3" } exports
  AGENTKIT_DEFAULT_PROFILE_<CLI> into containers when that profile is shared, so a
  bare ak claude inside uses that account (coding-agents-kit v0.5.2+); the macOS
  @default Claude login lives in the keychain and cannot be shared. dck doctor shows
  the mapping and flags a mapping it cannot apply.
• dck doctor: Docker Compose >= 2.24 (satellites with extends + !reset), a compose
  file that does not reflect dck.toml or its user block (dck up and dck rebuild
  warn too), and what the user block overrides (compose_render in --json).

Fixed

• The agents layer no longer replaces the image's Node. When the image's node was
  missing or older than the pinned major, the pinned Node was extracted over
  /usr/local, replacing a repository's production Node and mixing npm trees (an
  ak install codex could fail silently). It now goes into its own prefix
  (/opt/dck/node); ak install runs with it first on PATH and the npm-installed agent
  CLIs are launched on it, while the repository's node stays the shell's.
• A rebuilt peer's new host key reaches every container. dck herdr mesh (run from
  any repository) re-reads each running peer's sshd host key from the container itself
  and re-pins it before pushing, so the host's hop and every other container follow a
  peer rebuilt outside its own dck up.
• The host's git identity in every container. dck up, rebuild, start and
  restart push user.name, user.email and, when the host signs with SSH, the signing
  setup (key::<public key>, never a path or a private key) into the container user's
  git config (dck_git_identity_host); no ~/.gitconfig mount and no DCK_GIT_* in the
  repository's .env needed (a DCK_GIT_* value still wins for its key). dck doctor
  shows the identity and its source.
• The Dailybot CLI login survives rebuilds whether the dailybot layer or the
  repository installed the CLI: ~/.config/dailybot is always on the state volume.
• [compose] project wins over COMPOSE_PROJECT_NAME in the environment or the compose
  .env (passed with -p); dck doctor resolves the project the same way.

Changed

• Pins: herdr-peers v0.2.3 (HERDR_PEERS_TAG, verified by the sha256 of its
  SHA256SUMS, dad7faff…; tag commit ff7b7aa): state kept per machine, so a
  checkout bind-mounted into a container no longer shares the host's self.json.
• Pins: coding-agents-kit v0.5.2 (AGENTKIT_TAG; tag commit af25837, tarball
  sha256 12cbf6e2…, SHA256SUMS sha256 2bedc980…): reads
  AGENTKIT_DEFAULT_PROFILE_<CLI> ([agents] default_profile).
• Markers are all-or-nothing. A compose file or Dockerfile with some of dck's markers
  but not all, or with unbalanced markers, is refused with the fix instead of being
  replaced or appended to (a block appended at the end could land inside another
  mapping). A file without any dck marker is still proposed as a whole-file replacement.

Install

git clone --branch v0.3.3 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.3 (digests in the images workflow run).

devcontainer-kit v0.3.2

Interface stays 2.

Added

• The host's SSH keys inside containers, opt-in ([ssh] copy_keys = true in the host
  profile; off by default, a repository's dck.toml cannot set it). Tools that only offer
  key files, such as gh auth login, ignored the forwarded agent and asked to generate a
  new key. With it on, dck up binds the host's ~/.ssh read-only at ~/.ssh_host
  through a runtime compose overlay ($TMPDIR/dck-<uid>/<project>-sshkeys.yml), and every
  container start copies its id_* keys into the container's ~/.ssh on the state
  volume (private 0600, .pub 0644, refreshed when they change on the host, removed when
  removed there). dck's own config, config.d/, authorized_keys and
  known_hosts.dck-host are never touched, a key the container made itself is kept, and
  the agent forwarding is unchanged. Turning it off removes the copies at the next start.
  While it is on, the whole host ~/.ssh is readable inside (read-only), not only the
  id_* keys, and private keys rest in the state volume: the trade-off and the wipe are
  in docs/SECURITY.md. New entrypoint function dck_ssh_copy_keys.

• dck setup asks once, on a terminal, whether to copy the host's SSH keys (default no)
  and records the answer in the profile's [ssh] table.

• dck doctor reports the opt-in and the key file names (ssh keys copied: …, names
  only); doctor --json gains an optional ssh_keys object (enabled, reason,
  host_keys, copied).

• The agents layer installs coding-agents-kit's three skills (agentkit,
  agentkit-setup, agentkit-orchestrate) from the same verified release tarball into
  the image's shared skills directory; the entrypoint links them into every agent's
  skills directory at each start, so a recreate no longer loses them.

• The repository dogfoods its own container (.devcontainer/, docker/local/,
  dev.sh): python-3.13 with every coding-agents-kit CLI, Herdr, herdr-peers and
  shellcheck, registered as a Herdr machine; the unit gate runs inside.

Fixed

• [compose] state_volume in dck.toml (and dck init --state-volume NAME): the
  name of the service's state volume (sshd host key, ~/.ssh, gh auth, Herdr client
  state, history). It was hardcoded as state, so repositories sharing one compose
  project (one COMPOSE_PROJECT_NAME) all mounted one <project>_state volume. The
  default stays state, so no existing install loses its volume; only the compose
  volume's name changes, the mount point (~/.dck/volumes/state) does not. The agents
  layer's volumes stay shared by name.
• dck doctor flags a compose project shared with other services whose state volume is
  not per service (or another service mounting the same state volume), with the fix;
  doctor --json gains an optional compose object. The doctor now resolves the compose
  project like the launcher and compose (COMPOSE_PROJECT_NAME from the environment or
  the compose directory's .env before the file's name:).
• dck doctor says when Claude's default account will not be logged in inside (its
  host login is the macOS keychain, never shared, and CLAUDE_CODE_OAUTH_TOKEN is not in
  ak's env file), with both fixes, instead of a bare "not copied" line.
• A container built from scratch reaches the host and its peers at once: dck rebuild,
  dck start and dck restart now run the same post-start steps as dck up — the Herdr
  machine is registered (re-added when it was removed, its host key re-pinned), the mesh
  and the host-catalog mirror are pushed, and the layout is created. A rebuild after the
  volumes were removed left an empty Herdr catalog inside until dck herdr mesh ran by
  hand.

Changed

• Pins: coding-agents-kit v0.5.1 (AGENTKIT_TAG; tag commit 48c38f8, tarball
  sha256 62cde0e8…, SHA256SUMS sha256 400e8fd6…).
• Agent tooling: the vendored deepworkplan skill moves to v7.6.1 (skills-lock.json,
  AGENTS.md provenance), through the pack's own addon planner; the AI Diff Reviewer
  stays at v3.3.9, the pack's pin.

Install

git clone --branch v0.3.2 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.2 (digests in the images workflow run).

devcontainer-kit v0.3.1

Interface stays 2.

Fixed

• Host accounts keep working across dck up: the env file of [agents] host_profiles
  is now bound through its per-project directory (~/.config/dck/agents/<project>/env,
  in the container ~/.dck/host/agentkit/hostenv/env), not as a single file. Every
  dck up rewrites it atomically, and a single-file bind kept showing the old inode,
  so tokens went stale or unset in a running container until --recreate. The v0.3.0
  file ~/.config/dck/agents/<project>.env is removed on the next dck up.
• A removed state volume no longer breaks dck ssh and dck herdr add (and dck up
  with Herdr on) behind a bare "sshd does not answer": the host key is pinned from the
  container itself through docker exec (new entrypoint helper dck_host_key_pub), and
  a changed key is re-pinned with a note. When the key cannot be read (an older image),
  a mismatch is named with the exact ssh-keygen -R <alias> -f … fix.

Changed

• Pins: herdr-peers v0.2.2 (HERDR_PEERS_TAG, verified by the sha256 of its
  SHA256SUMS): Codex lanes pass --pane, and list shows full machine ids.
• Agent tooling: the vendored deepworkplan skill moves to v7.6.0 and the AI Diff
  Reviewer skill to v3.3.9 (skills-lock.json, .dwp/config.json, AGENTS.md
  provenance), through the pack's own addon planner.
• Docs: no agent keys through Claude's bypass-permissions acknowledgement. A leftover one
  is escalated to the developer, who accepts it once per profile; folder trust is the only
  screen an agent may key through, and only on a pane it launched itself when
  --trust-cwd was unavailable (docs/layers.md, the dck skill, docs/SECURITY.md).

Install

git clone --branch v0.3.1 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.1 (digests in the images workflow run).

devcontainer-kit v0.3.0

Interface stays 2: every new key is optional and off by default.

Added

• Containers can use the host's agent accounts ([agents] host_profiles = true, host
  profile only — a repository's dck.toml cannot turn it on). dck up adds a runtime
  compose overlay, never written into the repository, that binds the host's
  coding-agents-kit profiles of the CLIs the repository installs ([agents] clis;
  claude, codex, pi, cline, grok, opencode — never cursor, whose profiles hold absolute
  host symlinks), one bind per profile, with AGENTKIT_PROFILES_DIR pointing at them;
  [agents] host_profile_names limits them to the profiles listed ("claude@work1").
  Also the host's Codex home (codex@default) when codex is installed, and a generated
  env file (0600, under ~/.config/dck/agents/) read-only with AGENTKIT_ENV pointing
  at it. Mounts are read-write only where the CLI writes, each reason documented and
  shown by the doctor. The env file has no implicit secret: only the Claude token of
  each shared Claude profile and the exact names in [agents] host_env_keys; with the
  option off nothing is copied. Values never appear in compose files, logs or the
  doctor; the names do.
• dck doctor reports the shared profiles with their mount mode and reason, the env
  file's names and, from the host's
  ak profiles --json (profiles-v1, coding-agents-kit v0.5.0+), the Claude profiles
  that log in through the macOS keychain without a token variable (with the fix:
  claude setup-token, then store it in ak's env file as CLAUDE_CODE_OAUTH_TOKEN_<SUFFIX>).
  doctor --json gains an optional host_profiles object (profiles, mounts, …).
• Unattended agent launches. With autonomy on, the entrypoint marks the app path as
  trusted for Claude and Codex at each start — in the container's own CLI homes and in
  shared host profiles — and writes Claude's bypass-permissions acknowledgement only in
  the container's own homes, never in a shared host profile. AGENTKIT_PERMISSIONS=ask
  writes neither. The Herdr fallback for a screen that still appears is documented.

Changed

• The agents layer installs coding-agents-kit v0.5.0 (AGENTKIT_TAG, verified by
  AGENTKIT_SHA256): accounts and quota (ak usage, ak pick), the per-profile Claude
  token (CLAUDE_CODE_OAUTH_TOKEN_<SUFFIX>) and ak profiles --json (profiles-v1),
  which host_profiles and dck doctor build on.
• Pins: herdr-peers v0.2.1 (HERDR_PEERS_TAG, verified by the sha256 of its
  release SHA256SUMS) inside the images and for dck host peers install, and
  deepworkplan-vim v0.7.0 (DWP_VIM_TAG, its tag commit and installer sha256) as
  the editor.
• With host_profiles on, dck up uses the compose backend (the overlay is a compose
  file the devcontainer CLI never reads).
• The test suite is PATH-hermetic: the developer's own ak, herdr, herdr-peers,
  dck and agent CLIs are hidden from every test, and AGENTKIT_*, HERDR_*,
  CLAUDE_*, CODEX_* and credential-shaped variables are cleared in the sandbox.

Security

• Credential sharing is opt-in and documented in docs/SECURITY.md: Codex auth.json
  is shared read-write, so keep one active writer per account.

Upgrade: install v0.3.0, then (optionally) set [agents] host_profiles = true in your
host profile and dck up --recreate.

Install

git clone --branch v0.3.0 https://github.com/DailybotHQ/devcontainer-kit
./devcontainer-kit/install.sh

Verify a clone with shasum -a 256 -c SHA256SUMS. Images: ghcr.io/dailybothq/devcontainer-kit-base:{python-3.13,node-24,debian}-v0.3.0 (digests in the images workflow run).