Creating and using build containers

[qume]

I have been using Nanoclaw, but really like the way this project is implemented and want to swap, however when I ask AlexClaw to clone a repo and create a container to build it in and make changes, it refuses.

I can extend it with functionality to do this, but there would be a number of ways to do it, i'm curious @thatsme thoughts on the best way to go about this

[thatsme]

Thanks for the kind words, and welcome from NanoClaw! 🦇

Before suggesting an approach, I'd love to understand the use case better — what were you trying to accomplish exactly? Clone a repo to review it, build and run it, make changes and commit back, or something else entirely?

AlexClaw's dynamic skills engine is designed exactly for this kind of extension, so depending on what you're doing there are a few different paths (a Docker skill, a shell execution skill, or something more targeted). The answer changes quite a bit based on the actual workflow you have in mind.

[thatsme]

One thing worth clarifying while you think about your use case: the Conversational skill is a pure LLM interface — it reasons and responds, but it doesn't execute anything on your system. So asking it to "clone a repo" will get you a very polite explanation of how to clone a repo, not an actual clone.

If you want AlexClaw to actually run shell commands, interact with Docker, or perform actions on your machine, that logic lives in a skill. The good news: AlexClaw runs on your hardware, so a Shell or Docker skill has full access to your local environment — no sandboxing overhead, no remote API, just your machine.

Check out test/fixtures/skills/skill_template.ex for the full SkillAPI reference — it's the fastest way to understand what a skill can do and how to wire it up.

[thatsme]

The right pattern for shell execution

A workflow combining llm_transform + a Shell skill handles this cleanly:

Trigger (e.g. Telegram: /clone https://github.com/user/repo)
  └── llm_transform step
        "Extract the repo URL and return: {\"cmd\": \"git clone <url> /workspace/<repo_name>\"}"
  └── ShellExec skill
        runs System.cmd("sh", ["-c", cmd]) → returns stdout/stderr
  └── llm_transform step (optional)
        summarizes result back via Telegram

The Docker constraint

Since AlexClaw runs inside a Docker container, any git clone will land inside the container filesystem — ephemeral and not accessible from your host. To clone into your host machine, mount a host directory in docker-compose.yml:

volumes:
  - /home/youruser/projects:/workspace  # host path : container path
  - skills_data:/app/skills

Your Shell skill then clones to /workspace/<repo>, which maps directly to /home/youruser/projects/<repo> on the host.

Shell skill (coming in next release)

A proper Shell skill with fine-grained permission controls (allowed commands, path restrictions, timeout) is on the roadmap for the next release cycle. In the meantime, you can implement a basic version as a dynamic skill — drop a .ex file in the skills volume and AlexClaw hot-loads it immediately, no restart needed.

Happy to share a starting template if you want to go ahead before the official skill ships.

[qume]

Excellent thanks for the feedback. I'll give this pattern a try.

Off-topic: I've been evaluating multiple 'claws', and this one is orders of magnitude faster than the others. Probably because of dynamically using different models, but also I'm guessing the way it's built on Beam. Now i'm used to using it, the others are just painful

[thatsme]

Really glad to hear that!
You are not off-topic at all.
The BEAM foundation is exactly why — everything runs as lightweight concurrent processes, so workflows don't block each other. And the dynamic model routing means you get the right model for each task without paying the latency tax of always hitting the biggest one.

Feedback like yours is incredibly valuable — if you ever spot rough edges, weird behaviors, documentation inconsistencies, different behavior after new version bumps or have ideas for workflows, skills you'd like to see, don't hesitate to share.
Real-world usage from power users who actually push the system is what drives the best improvements.

Best, Alex

[qume]

The workflow triggering a skill worked, thanks for the heads up on that. The next step will be to be able to ask it to make changes - perhaps a workflow to hook up a long running claude code session to alexclaw could be the best way forward. Ultimately being able to have it modify a code change through telegram / chat interface is what I'm interested in exploring.

[thatsme]

To make sure I'm pointing you in the right direction — what's the primary interaction model you have in mind?

a) You send a task via Telegram ("fix this bug", "add this feature"), AlexClaw processes it autonomously and reports back when done
b) You want an interactive back-and-forth conversation with a Claude Code session, but through Telegram as the interface
c) Something else entirely

The architecture is quite different depending on which direction you're heading.