container_workspace_required remediation is blocked by WORKSPACE_NO_CLAIMED_TODO

[worldofgeese]

Summary

decapod validate reports a single auto-remediable failure, container_workspace_required, and tells the agent to rerun through decapod workspace ensure --container. That remediation path then fails with WORKSPACE_NO_CLAIMED_TODO, requiring decapod todo claim before spawning a container workspace.

This creates a control-plane deadlock for repositories that intentionally use an external task tracker instead of Decapod todos. In this repo, project overrides require Beads (bd) for task tracking and explicitly supersede decapod todo operations, but Decapod still hard-requires a claimed Decapod todo for the container workspace remediation.

Environment

• Decapod: v0.48.6 (decapod version)
• OS: Linux
• Container runtime: Docker-compatible runtime available (decapod workspace status reports docker_available: true; this machine uses rootless Podman/Docker-compatible tooling)
• Repository context: already inside a Decapod-managed git worktree on non-protected branch agent/unknown/test-01ks5pf9r46a1t6e

decapod workspace status:

{"blockers":0,"can_work":true,"container_image":null,"docker_available":true,"git_branch":"agent/unknown/test-01ks5pf9r46a1t6e","git_has_local_mods":false,"git_is_protected":false,"in_container":false,"required_actions":[]}

Reproduction

From an existing Decapod worktree with an active session and clean git state:

decapod validate -v

Observed failure:

summary pass=174 fail=1 warn=5
issues AUTOREMEDIABLE_VALIDATION_ERROR code=container_workspace_required severity=transient auto_remediable=true audience=agent agent_action="Agent: rerun through `decapod workspace ensure --container` ..."
! validation needs attention

Then follow the remediation:

decapod workspace ensure --container

Observed result:

session: auto-acquired for agent 'unknown'.
Error: ValidationError("AUTOREMEDIABLE_VALIDATION_ERROR code=WORKSPACE_NO_CLAIMED_TODO severity=transient auto_remediable=true audience=agent agent_action=\"claim a todo with `decapod todo claim --id <task-id>` before spawning a worktree\" user_note=\"No todo is assigned to this agent; the agent should claim an open task first.\"
No claimed or open todo assigned to agent 'unknown'. Agent must claim a todo before spawning a worktree.")

Expected behavior

One of these should be possible:

1. decapod workspace ensure --container should provide a remediation path that does not require Decapod todos when a repo uses an external task tracker or a project override supersedes Decapod todos.
2. decapod validate should not mark container_workspace_required as auto-remediable with an impossible command path.
3. Decapod should expose a supported way to satisfy/waive the claimed-work requirement using an external tracker claim, or project-level override metadata.

Actual behavior

The only advertised remediation for container_workspace_required requires decapod workspace ensure --container, but that command is blocked by a Decapod-todo precondition. In a repo where Decapod todos are explicitly superseded by Beads, following the remediation would violate the repo’s operating contract.

Why this matters

Agents cannot truthfully claim decapod validate passes, and they also cannot follow the suggested remediation without violating project policy. The result is a persistent validation failure even when all application-level proof gates pass and the work is being tracked/claimed in the project’s approved tracker.

[alexhraber]

Thanks for reporting the issue @worldofgeese -- this is generally safe to ignore if you are using decapod for the task/todo management system, and actually should autocreate a todo for the topic once decapod becomes aware of the task being worked on, which then would create the container.

Note, in your error log output, it is accurately detecting that the issue is AUTOREMEDIABLE_VALIDATION_ERROR.

I'll take a deeper look and see if there's a way we can more easily integrate beads tasks, and update this issue once a solution is in place.

Though, I stand by the fact that decapod should be creating a task anyways, so it'd be interesting to understand why it's not behaving that way here.

[alexhraber]

Addressed in PR #570

Resolved Container Deadlock (#568):
* Updated src/core/workspace.rs to allow decapod workspace ensure --container to proceed even if no tasks are
yet claimed. This allows agents to set up their required container environment before claiming work.
* Fixed src/lib.rs to correctly pass the workspace configuration when the --container flag is used without an
explicit branch name.
* Made branch scoping checks conditional on having assigned todos, allowing the workspace logic to operate
correctly during initial environment setup.

Doing some more testing before merging.

[alexhraber]

hey @worldofgeese I believe this is totally solved. You will still see some noisy errors but they're all actionable idiomatic errors that your agent will be instructed on how to continue.

Let me know if you continue experiencing this and re-open the ticket. Also, feel free to make any other issues, always happy to solve whatever people find to be a bug or nuisance.

Thanks for the perfectly written and detailed issue!