-
-
Notifications
You must be signed in to change notification settings - Fork 781
Description
Problem Statement
Problem / Motivation
I really love Auto-Claude’s workflow and UI, but I’m struggling to adopt it in teams where:
1. There are too many host dependencies to install (Node + Python + Docker Desktop + various setup steps). This is a big adoption barrier—especially for onboarding or locked-down corporate laptops.
2. Most of our codebases are developed in devcontainers, and getting Auto-Claude to run validation/build/test commands inside the devcontainer currently feels like extra plumbing. Since the tool creates worktrees, it’s even easier to get “runs on host” vs “runs in container” mismatches.
Overall: the project’s value is highest when setup is trivial and environment differences disappear.
Proposed Solution
Feature request
A) “Single install” distribution option (one thing to install / one file to download)
Please consider shipping one of the following (or equivalent):
• A single self-contained binary (e.g., via PyInstaller / Nuitka / similar) for the backend + bundled UI, so users download one installer and go.
• Or a single package manager entrypoint:
• brew install auto-claude (macOS) / winget (Windows) / apt (Linux), with everything bundled.
• Or a single Docker image that includes everything needed to run Auto-Claude (UI optional), with minimal host requirements.
The goal is: a new user should be able to install Auto-Claude with one command or one download, without separately installing Node/Python/etc.
Acceptance criteria (example):
• Fresh machine → install Auto-Claude via one step → point it at a repo → run.
• No separate “install Python/Node” docs for the common path.
B) Devcontainer-first execution mode (run commands in-container automatically)
Add a “Devcontainer Mode” (or “Container Execution Provider”) so that:
• Auto-Claude can detect devcontainer config (.devcontainer/devcontainer.json etc.)
• Worktree-aware commands (validate/test/build) automatically execute inside the devcontainer, not on the host.
• It works with both:
• devcontainer exec … (VS Code Dev Containers CLI)
• and/or docker compose exec … for compose-based devcontainers
Key requirement: worktree compatibility
Auto-Claude creates worktrees (e.g., .worktrees/). Devcontainer execution should run in the correct worktree path so tests validate the actual changes.
Suggested UX:
• Project setting: Execution environment
• Host (default)
• Devcontainer (devcontainer CLI)
• Docker Compose service (select service)
• And a “health check” button: verify container is running, can git status, can run configured test command.
Acceptance criteria (example):
• Repo with devcontainer, dependencies only installed inside container
• User runs “Start task” in UI
• Auto-Claude creates worktree
• Validation commands run inside the devcontainer in that worktree
• No extra wrapper scripts needed per-project
C) Optional: Make Memory Layer “plug-and-play”
If the Memory Layer requires Docker Desktop, consider offering:
• An embedded/local DB option (sqlite or similar) for “lite mode”
• Or let the Docker container distribution include it, so the host does not need Docker Desktop for the common path
Why this would be a big win
• Removes the #1 adoption blocker: long install/setup.
• Aligns with how many teams build software today: containerized dev environments.
• Reduces “works on my machine” drift between host and container.
• Makes onboarding as easy as “install once, open repo, run”.
Thanks for building this—this would make it dramatically easier to roll out widely.
Alternatives Considered
No response
Component
Python Backend (auto-claude/)
How important is this feature to you?
None
Contribution
- I'm willing to submit a PR for this feature
Additional Context
No response