cleveragents/cleveragents-core

Fork 3

UAT: `ToolRunner` returns error for `ExecutionEnvironment.CONTAINER` — lazy activation via tool use not functional in production (F24) #4910

New issue

Open

opened 2026-04-08 20:18:40 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-08 20:18:40 +00:00

Owner

Bug Report

Feature Area: Devcontainer Integration — Execution Environment Routing + Lazy Activation
ADR Reference: ADR-043 §Execution Environment Routing, §Lifecycle: Lazy Activation
Severity: Medium (lazy activation via tool execution not functional; core ADR-043 use case broken)

What Was Tested

ADR-043 specifies that when a plan executes a tool and the execution environment resolves to a devcontainer, the system should trigger lazy activation of the container. This is the primary mechanism for the "lazy activation" feature.

Expected Behavior (from ADR-043)

Building (provisioning_state: building): When a plan first needs to execute a tool inside the devcontainer, the system triggers the build.

The flow should be:

Plan executes a tool.
Execution environment resolver selects the devcontainer (Level 3 in the 6-level chain).
ToolRunner routes the tool to the container.
DevcontainerHandler.resolve() is called, which triggers activate_container() if the container is in DETECTED/STOPPED/FAILED state.
Container is built and the tool executes inside it.

Actual Behavior

ToolRunner returns an error when ExecutionEnvironment.CONTAINER is resolved:

From docs/reference/devcontainer_resources.md:

Container execution stubbed (F24): ToolRunner returns an error for ExecutionEnvironment.CONTAINER, so lazy activation cannot trigger via tool use in production. Lazy activation currently works through DevcontainerHandler.resolve() on plan sandbox resolution.

This means:

The DevcontainerHandler.resolve() lazy activation code path exists and is correct.
But ToolRunner never reaches it because it returns an error before routing to the container.
The only way lazy activation currently triggers is through direct sandbox resolution (not via tool execution).

Code Locations

Known limitation: docs/reference/devcontainer_resources.md:254
Lazy activation in handler: src/cleveragents/resource/handlers/devcontainer.py:310-356 — correct implementation, but unreachable via tool execution
ToolRunner container routing: needs investigation in src/cleveragents/tool/ or src/cleveragents/runtime/

Impact

The primary ADR-043 use case (tool execution triggering devcontainer build) does not work.
Users cannot use agents plan use with a devcontainer-backed project and expect the container to be built automatically.
The lazy activation feature is effectively non-functional for end-to-end workflows.
ADR-043 compliance test "Lazy activation tests: Devcontainer resources remain in discovered state until a plan requires execution, then transition through building → active" cannot be validated end-to-end.

Fix Required

Implement container execution routing in ToolRunner:

When ExecutionEnvironment.CONTAINER is resolved, look up the container resource for the project.
Call DevcontainerHandler.resolve() (or activate_container() directly) to ensure the container is running.
Route the tool execution into the container via devcontainer exec.
Return the tool result from the container execution.

This is tracked as issue #616 per the documentation.

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report **Feature Area:** Devcontainer Integration — Execution Environment Routing + Lazy Activation **ADR Reference:** ADR-043 §Execution Environment Routing, §Lifecycle: Lazy Activation **Severity:** Medium (lazy activation via tool execution not functional; core ADR-043 use case broken) --- ## What Was Tested ADR-043 specifies that when a plan executes a tool and the execution environment resolves to a devcontainer, the system should trigger lazy activation of the container. This is the primary mechanism for the "lazy activation" feature. ## Expected Behavior (from ADR-043) > 2. **Building** (`provisioning_state: building`): When a plan first needs to execute a tool inside the devcontainer, the system triggers the build. The flow should be: 1. Plan executes a tool. 2. Execution environment resolver selects the devcontainer (Level 3 in the 6-level chain). 3. `ToolRunner` routes the tool to the container. 4. `DevcontainerHandler.resolve()` is called, which triggers `activate_container()` if the container is in `DETECTED`/`STOPPED`/`FAILED` state. 5. Container is built and the tool executes inside it. ## Actual Behavior `ToolRunner` returns an error when `ExecutionEnvironment.CONTAINER` is resolved: From `docs/reference/devcontainer_resources.md`: > **Container execution stubbed (F24):** `ToolRunner` returns an error for `ExecutionEnvironment.CONTAINER`, so lazy activation cannot trigger via tool use in production. Lazy activation currently works through `DevcontainerHandler.resolve()` on plan sandbox resolution. This means: - The `DevcontainerHandler.resolve()` lazy activation code path exists and is correct. - But `ToolRunner` never reaches it because it returns an error before routing to the container. - The only way lazy activation currently triggers is through direct sandbox resolution (not via tool execution). ## Code Locations - Known limitation: `docs/reference/devcontainer_resources.md:254` - Lazy activation in handler: `src/cleveragents/resource/handlers/devcontainer.py:310-356` — correct implementation, but unreachable via tool execution - ToolRunner container routing: needs investigation in `src/cleveragents/tool/` or `src/cleveragents/runtime/` ## Impact - The primary ADR-043 use case (tool execution triggering devcontainer build) does not work. - Users cannot use `agents plan use` with a devcontainer-backed project and expect the container to be built automatically. - The lazy activation feature is effectively non-functional for end-to-end workflows. - ADR-043 compliance test "Lazy activation tests: Devcontainer resources remain in `discovered` state until a plan requires execution, then transition through `building` → `active`" cannot be validated end-to-end. ## Fix Required Implement container execution routing in `ToolRunner`: 1. When `ExecutionEnvironment.CONTAINER` is resolved, look up the container resource for the project. 2. Call `DevcontainerHandler.resolve()` (or `activate_container()` directly) to ensure the container is running. 3. Route the tool execution into the container via `devcontainer exec`. 4. Return the tool result from the container execution. This is tracked as issue #616 per the documentation. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 referenced this issue

2026-04-08 20:19:48 +00:00

[Automated] CleverAgents Build Session - 2026-04-08 #4799

HAL9000 referenced this issue

2026-04-08 20:22:25 +00:00

[Automated] CleverAgents Build Session - 2026-04-08 #4799

HAL9000 referenced this issue

2026-04-08 22:58:56 +00:00

Proposal: improve uat-tester — enforce label compliance when filing bug issues #4924

HAL9000 added the

labels

2026-04-08 22:59:16 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-08 23:01:04 +00:00

HAL9000 commented

2026-04-08 23:07:07 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Medium — lazy activation via tool execution is non-functional; ToolRunner returns error for ExecutionEnvironment.CONTAINER; core ADR-043 use case broken
Milestone: v3.5.0 — Devcontainer integration and lazy activation is scoped to Autonomy Hardening milestone per ADR-043
Story Points: 5 — L — requires implementing container execution routing in ToolRunner: resolve container resource, trigger activation, route tool via devcontainer exec
MoSCoW: Should Have — primary ADR-043 use case (tool execution triggering devcontainer build) must work for v3.5.0 acceptance; tracked as issue #616 per docs
Parent Epic: Devcontainer Integration epic (v3.5.0)

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Medium — lazy activation via tool execution is non-functional; `ToolRunner` returns error for `ExecutionEnvironment.CONTAINER`; core ADR-043 use case broken - **Milestone**: v3.5.0 — Devcontainer integration and lazy activation is scoped to Autonomy Hardening milestone per ADR-043 - **Story Points**: 5 — L — requires implementing container execution routing in `ToolRunner`: resolve container resource, trigger activation, route tool via `devcontainer exec` - **MoSCoW**: Should Have — primary ADR-043 use case (tool execution triggering devcontainer build) must work for v3.5.0 acceptance; tracked as issue #616 per docs - **Parent Epic**: Devcontainer Integration epic (v3.5.0) --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

freemo added a new dependency

2026-04-08 23:42:07 +00:00

#4952 EPIC: Devcontainer Lifecycle Management — State Persistence & Auto-Discovery

freemo referenced this issue

2026-04-08 23:43:07 +00:00

LEGENDARY: Autonomy Hardening — Full Autonomous Execution, Safety & A2A Facade #4944

HAL9000 added the

Points

label

2026-04-09 05:42:40 +00:00

HAL9000 commented

2026-04-09 05:43:04 +00:00

Author

Owner

Label compliance fix applied:

Added missing label: Points/3 (M — medium complexity)
Reason: Issue is in State/Verified but was missing a story points estimate. Estimated as Points/3 (M) based on single-area bug fix with moderate complexity.

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: backlog-groomer

Label compliance fix applied: - Added missing label: `Points/3` (M — medium complexity) - Reason: Issue is in `State/Verified` but was missing a story points estimate. Estimated as Points/3 (M) based on single-area bug fix with moderate complexity. --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: backlog-groomer

HAL9000 referenced this issue

2026-04-10 21:52:10 +00:00

EPIC: Devcontainer Lifecycle Management — State Persistence & Auto-Discovery #4952