Summary
The agent cannot use any commandline tools since the official Docker container (and the only Dockerfile in the project) is based on a distroless image which has no shell.
Problem statement
This makes working on git repositories or any other file-based operations impossible. All Tools ran through the shell tool fail, like pwd, ls, etc. only the tools for manipulating the files directly (write_file, read_file, etc.) work.
Proposed solution
Switch to a more common base image for the official Docker build (like debian) or at least provide another Dockerfile and pre-built image to stay secure by default. This will allow the agent to have it's own home directly (the workspace) while other directories still cannot be accessed due to the restrictions of ZeroClaw itself.
Non-goals / out of scope
No response
Alternatives considered
Building the Docker image myself with another base image. However, this is tedious and takes forever if done frequently (e.g. on updates) and is error prone.
Acceptance criteria
No response
Architecture impact
docs/, Dockerfile*, .github/workflows/
Risk and rollback
Risk is that this MAY be breaking due to the switch of the base image. This is why i propose to just add another Dockerfile and another "image flavor" for prebuilt-images (e.g. by using different tags like zeroclaw-labs/zeroclaw:debian-latest instead of just :latest).
Breaking change?
No
Data hygiene checks
Summary
The agent cannot use any commandline tools since the official Docker container (and the only Dockerfile in the project) is based on a distroless image which has no shell.
Problem statement
This makes working on git repositories or any other file-based operations impossible. All Tools ran through the
shelltool fail, likepwd,ls, etc. only the tools for manipulating the files directly (write_file,read_file, etc.) work.Proposed solution
Switch to a more common base image for the official Docker build (like debian) or at least provide another Dockerfile and pre-built image to stay secure by default. This will allow the agent to have it's own home directly (the workspace) while other directories still cannot be accessed due to the restrictions of ZeroClaw itself.
Non-goals / out of scope
No response
Alternatives considered
Building the Docker image myself with another base image. However, this is tedious and takes forever if done frequently (e.g. on updates) and is error prone.
Acceptance criteria
No response
Architecture impact
docs/, Dockerfile*, .github/workflows/
Risk and rollback
Risk is that this MAY be breaking due to the switch of the base image. This is why i propose to just add another Dockerfile and another "image flavor" for prebuilt-images (e.g. by using different tags like
zeroclaw-labs/zeroclaw:debian-latestinstead of just:latest).Breaking change?
No
Data hygiene checks