Release 1.14.4 - #118
Merged
Merged
Release 1.14.4#118
Conversation
The lab container has none: no compose file here sets `working_dir`, no lab Dockerfile sets `WORKDIR`, and neither base image does either — so `Config.WorkingDir` is empty and the container starts in `/`. That is where the container's command runs, and where a `docker compose exec` with no `--workdir` of its own lands. It is invisible while the command is `sleep infinity` and the operator cd's on arrival. It stops being invisible the moment an agent IS the command: run Claude Code that way and it takes `/` for its project — asks to trust `/`, and files its per-project state under that key rather than the workspace's. Reported against a sal-managed lab pinned to v1.14.2, where the deployment's compose.override.yaml runs the agent as the lab's command. Measured rather than assumed, against compose v5.1.4: `working_dir: /workspace` sets the container's WorkingDir, so the command starts there, AND becomes the default for `docker compose exec`, so a shell lands there too. One key covers both ways in. Three files, and the fourth is a deliberate exception. stack/compose.yaml and template/deployment/compose.yaml mount the workspace and are what everything else is copied from; examples/dev-container mounts it too, and while devcontainer.json's `workspaceFolder` already covers the terminals VS Code opens, it covers neither the container's command nor a hand-run exec. examples/claude-code is left alone: its lab image carries `WORKDIR /home/agent` on purpose and its project mount is commented out for the copier to fill in. The lint is conditional on the mount for that reason — a lab that mounts a workspace must name it as its working directory, and one that mounts none is skipped. Checked by removing the key: it fails, naming the file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014rMYm8edXNCitmwZfc2MTv
Give the lab a working directory
The release is #117 and nothing else: `working_dir: /workspace` on the lab service of stack/, the template and the dev-container example, plus the conditional lint that keeps it there. No image, bank entry or provider file changed, so there is nothing to rebuild. The Upgrading section carries the one manual step, and it is a real one for once: the template is a file people copied, not something fetched at build time, so repinning does not deliver this fix to an existing deployment — the key has to be added to its own compose.yaml by hand. It matters wherever an agent runs as the lab's command and is cosmetic otherwise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BLuSkuyQUfogZpMJ5fVMF9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cuts 1.14.4. The release is #117 and nothing else.
What's in it
The lab container gets a working directory. No compose file set
working_dir, no labDockerfilesetWORKDIR, and neither base image sets one — soConfig.WorkingDirwas empty and the container started in/, both for its own command and for adocker compose execgiven no--workdirof its own.Invisible while the command is
sleep infinityand the operatorcds on arrival; not invisible once an agent is the command, which is how asal-managed lab runs one. Claude Code then takes/for its project — asks to trust/, and files its per-project state under that key instead of the workspace's.working_dir: /workspaceonstack/, the template and the dev-container example, plus a lint conditional on the workspace mount soexamples/claude-codeis excluded by rule rather than by list.This PR
CHANGELOG.md— the 1.14.4 entry.template/deployment/compose.yaml— repinnedv1.14.3→v1.14.4across all five services.Upgrading is a real step this time
Most entries here say "nothing to do". This one does not: the template is a file people copied, not something fetched at build time, so repinning does not carry the fix into an existing deployment —
working_dir: /workspacehas to be added to its owncompose.yamlby hand. It matters wherever an agent runs as the lab's command and is cosmetic otherwise. No image, bank entry or provider file changed, so there is nothing to rebuild.Checks
00-config-lint418 passed / 0 failed / 1 skipped,05-check-drift36/0 — both after the repin.Expect
tests/stacks/20-boundaryto skip the template for the life of this PR: the repin namesv1.14.4, which is only created once this merges, so nothing can build from it yet.🤖 Generated with Claude Code
https://claude.ai/code/session_01BLuSkuyQUfogZpMJ5fVMF9