Operating System
Linux (WSL2)
Run Mode
Docker
App Version
0.13.0 (commit 0424b171)
Bug Description
When Automaker runs in Docker with project volume mounts (/host/path:/projects), git worktrees are created using container paths (/projects/...) which don't exist on the host filesystem. This causes worktree operations to fail silently, leaving features permanently stuck in waiting_approval state even after the UI shows successful commit/merge operations.
Root Cause Analysis
Location: apps/server/src/routes/worktree/routes/create.ts:164-201
When Automaker creates worktrees in Docker:
- Container sees project at:
/projects/OwenAI
- Worktree created at:
/projects/OwenAI/.worktrees/feature-name
- Git records this absolute path in
.git/worktrees/
When host git tries to access the worktree:
- Host sees project at:
/home/user/automaker-projects/OwenAI
- Git looks for worktree at:
/projects/OwenAI/.worktrees/feature-name (doesn't exist)
- Worktree marked as "prunable" in
git worktree list
- Merge operations fail silently
Evidence from git reflog:
7e1304a HEAD@{2026-01-31 17:12:10 +0800}: merge feature/...: Merge made by the 'ort' strategy.
This merge only succeeded when performed manually on the host, not through Automaker UI.
Docker configuration (docker-compose.override.yml:20):
volumes:
- /home/jason/automaker-projects:/projects
Steps to Reproduce
- Run Automaker in Docker with volume mount:
~/automaker-projects:/projects
- Create a new feature in auto worktree mode
- Let agent complete the feature implementation
- In Automaker UI, click "Commit" and then "Merge" on the feature
- UI shows success, feature status becomes "waiting_approval"
- On host, run:
git worktree list - worktree shows as "prunable"
- Check
git log - no merge commit exists
- Feature remains stuck in
waiting_approval state
Expected Behavior
One of:
- Worktrees created with paths that work from both container and host
- Container operations translate paths when writing git metadata
- Documentation warns about this limitation and provides workaround
- Merge operations detect and repair broken worktree paths
Actual Behavior
- UI shows "success" for commit/merge operations
- Feature status:
"status": "waiting_approval"
- Execution state shows:
"runningFeatureIds": ["feature-..."]
- No merge happens, branch remains unmerged
- Worktree path broken:
/projects/... doesn't exist on host
git worktree list shows worktree as "prunable"
- No error visible to user
Impact
- Silent failure: Users believe work is merged when it isn't
- Stuck features: Manual intervention required for every feature
- Data loss risk: Worktrees may be accidentally pruned
- Affects all Docker users with volume mounts
Manual Workaround
On host filesystem:
cd ~/automaker-projects/ProjectName
git worktree prune
git merge feature/branch-name --no-edit
git push
# Manually update .automaker/features/*/feature.json status to "completed"
Suggested Fix
Option 1: Relative paths (simplest)
In create.ts:164-165, use relative paths for worktrees:
const worktreesDir = '.worktrees'; // relative, not absolute
const worktreePath = path.join(worktreesDir, sanitizedName);
Option 2: Path translation
Create a path translation layer that converts between container and host paths when reading/writing git metadata.
Option 3: Documentation
If fixing is complex, document that Docker users must run git operations on host, or use bind mounts that preserve paths.
Related Issues
Additional Context
Feature metadata (.automaker/features/.../feature.json):
{
"status": "waiting_approval",
"branchName": "feature/add-structured-idea-extraction-with-progress-track-v96v"
}
Execution state (.automaker/execution-state.json):
{
"projectPath": "/projects/OwenAI",
"runningFeatureIds": ["feature-1769843195905-ybn9nwf55"]
}
The /projects/... path is the container path, not the host path.
Environment Details
# docker-compose.override.yml
volumes:
- /home/jason/automaker-projects:/projects # Host path : Container path
Git operations inside container work fine. Git operations on host fail because paths don't match.
Operating System
Linux (WSL2)
Run Mode
Docker
App Version
0.13.0 (commit 0424b171)
Bug Description
When Automaker runs in Docker with project volume mounts (
/host/path:/projects), git worktrees are created using container paths (/projects/...) which don't exist on the host filesystem. This causes worktree operations to fail silently, leaving features permanently stuck inwaiting_approvalstate even after the UI shows successful commit/merge operations.Root Cause Analysis
Location:
apps/server/src/routes/worktree/routes/create.ts:164-201When Automaker creates worktrees in Docker:
/projects/OwenAI/projects/OwenAI/.worktrees/feature-name.git/worktrees/When host git tries to access the worktree:
/home/user/automaker-projects/OwenAI/projects/OwenAI/.worktrees/feature-name(doesn't exist)git worktree listEvidence from git reflog:
This merge only succeeded when performed manually on the host, not through Automaker UI.
Docker configuration (
docker-compose.override.yml:20):Steps to Reproduce
~/automaker-projects:/projectsgit worktree list- worktree shows as "prunable"git log- no merge commit existswaiting_approvalstateExpected Behavior
One of:
Actual Behavior
"status": "waiting_approval""runningFeatureIds": ["feature-..."]/projects/...doesn't exist on hostgit worktree listshows worktree as "prunable"Impact
Manual Workaround
On host filesystem:
Suggested Fix
Option 1: Relative paths (simplest)
In
create.ts:164-165, use relative paths for worktrees:Option 2: Path translation
Create a path translation layer that converts between container and host paths when reading/writing git metadata.
Option 3: Documentation
If fixing is complex, document that Docker users must run git operations on host, or use bind mounts that preserve paths.
Related Issues
Additional Context
Feature metadata (
.automaker/features/.../feature.json):{ "status": "waiting_approval", "branchName": "feature/add-structured-idea-extraction-with-progress-track-v96v" }Execution state (
.automaker/execution-state.json):{ "projectPath": "/projects/OwenAI", "runningFeatureIds": ["feature-1769843195905-ybn9nwf55"] }The
/projects/...path is the container path, not the host path.Environment Details
Git operations inside container work fine. Git operations on host fail because paths don't match.