ACP/Zed: task tool crashes with 'this.isRunning is not a function' and todo_pause does not stop the continuation loop

[acoliver]

Summary

Two bugs manifest exclusively in ACP/Zed mode (not in the interactive CLI), causing the task tool to crash and the todo_pause tool to fail to stop the agent continuation loop.

Bug 1: this.isRunning is not a function when the task tool is invoked

Error:

{"type":"tool_response","callId":"call_CAQhiZPfNrzC3aT0QHXZt0ag","toolName":"task","result":{"error":"this.isRunning is not a function. (In 'this.isRunning()', 'this.isRunning' is undefined)"}}

Root cause: In packages/agents/src/core/subagentExecution.ts, the initInteractiveScheduler() function creates a facade object that copies the scheduler's schedule method without binding it:

return {
  scheduler: {
    schedule: scheduler.schedule,  // ← receiver lost!
    awaitCompletedCalls: channel.awaitCompletedCalls,
  },
  ...
};

When scheduler.schedule() is later called through the facade, JavaScript sets this to the facade object, not the original CoreToolScheduler. The facade has no isRunning() method, so CoreToolScheduler.schedule() crashes when it calls this.isRunning().

Why only in ACP/Zed: The interactive CLI registers its own schedulerFactoryProvider via interactiveToolScheduler.ts, which correctly uses a closure ((req, sig) => instance.schedule(req, sig)). ACP/Zed does not register a scheduler factory, so the fallback path through initInteractiveScheduler() is taken — exposing the unbound method.

Fix: Replace schedule: scheduler.schedule with schedule: (req, sig) => scheduler.schedule(req, sig) in subagentExecution.ts.

Bug 2: todo_pause does not stop the continuation loop

Symptom: When the model calls todo_pause, the agent continues looping instead of stopping. In the CLI this works because the React UI layer has a separate continuation gate (useTodoContinuation.ts) that checks todoPaused. ACP/Zed has no such outer gate.

Root cause: AgenticLoop.buildNextMessage() unconditionally returns continueLoop: true for any successful tool — including todo_pause:

// AgenticLoop.ts — buildNextMessage()
const responseParts = buildToolResponses(agentTools);
if (responseParts.length === 0) {
  return { continueLoop: false, nextMessage: [] };
}
return { continueLoop: true, nextMessage: responseParts };  // ← always continues

There is no check for todo_pause being among the completed tools. The MessageStreamOrchestrator's todoPauseSeen logic is correct but it only observes events from Turn.run(), which emits ToolCallRequest (not ToolCallResponse) for model tool blocks. The actual tool responses are produced later by the AgenticLoop scheduler, which never checks for todo_pause.

Reproduction evidence: Running scripts/test-acp-zed-bugs.mjs confirms the todo_pause scenario times out (the loop never completes), while a normal prompt completes successfully.

Fix: In AgenticLoop.buildNextMessage(), detect a successful todo_pause among the completed tools and return continueLoop: false. Also eagerly record the tool history (via recordCompletedToolHistory from loopHelpers.ts) since there won't be a next model turn to carry the response.

Reproduction

A cross-platform test script has been added at scripts/test-acp-zed-bugs.mjs:

node scripts/test-acp-zed-bugs.mjs --profile <profile-name>

It spawns the llxprt-code process in --experimental-acp mode, performs the ACP handshake, and sends prompts designed to trigger both bugs. Works on Windows, macOS, and Linux.

Impact

• The task tool is completely unusable in Zed/ACP mode
• The todo_pause tool (used for loop-breaking) is non-functional in Zed/ACP mode, causing infinite loops and wasted tokens
• These are core agent loop features that should work identically across all frontends

[acoliver]

@coderabbitai plan

[coderabbitai]

🔗 Related PRs

#2097 - Fix error-on-cancel and ESC not cancelling subagents (Fixes #2076, Fixes #2074) [merged]
#2125 - Fix #2099: Cancelling a tool call from a subagent during parallel tool calls can cause a hang [merged]
#2163 - fix(core): resolve tool-name and async-guidance prompt token leaks (Fixes #2109) [merged]
#2382 - Interactive CLI consumes agent.stream() instead of assembling the agentic loop (Fixes #2372) [merged]
#2385 - Port Zed integration onto Agent API; delete hand-rolled chat loop (Fixes #2375) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Bug 1: replace the unbound schedule method reference in subagentExecution.ts's initInteractiveScheduler() fallback facade with a receiver-preserving closure, matching the existing CLI pattern.
• Bug 2: add AgenticLoop-level detection of a successful todo_pause (reusing the established name+no-error semantics and shared tool-name constant) that short-circuits the loop and eagerly records tool history, so ACP/Zed stops looping without relying on the CLI's outer React gate.
• Add targeted unit tests for both fixes and create the missing scripts/test-acp-zed-bugs.mjs reproduction/verification script.

Implementation Steps

Phase 1: Restore scheduler receiver binding (Bug 1)

Fix the method-detachment bug so the task tool works in ACP/Zed mode by ensuring the scheduler facade preserves the underlying CoreToolScheduler instance as the receiver when schedule is invoked.

Task 1: Wrap `schedule` in a closure in `initInteractiveScheduler()`

Preserve this binding when the scheduler facade's schedule is later called.

• In packages/agents/src/core/subagentExecution.ts, inside initInteractiveScheduler()'s returned facade, replace the bare method reference schedule: scheduler.schedule with an arrow-function closure that invokes scheduler.schedule(request, signal) using method-call syntax.
• Mirror the exact style already used in packages/cli/src/runtime/interactiveToolScheduler.ts ((request, signal) => instance.schedule(request, signal)) so the receiver resolves to the real scheduler instance at call time.
• Leave awaitCompletedCalls and schedulerDispose unchanged.

Task 2: Add regression coverage for the fallback facade

Guard against future re-introduction of the detachment bug on the ACP/Zed fallback path.

• Add a unit test (extend packages/agents/src/core/subagentExecution.test.ts) that exercises initInteractiveScheduler() on the fallback branch (no schedulerFactory provided) and asserts that invoking the returned facade's schedule(...) correctly reaches the underlying scheduler instance's schedule with the right receiver (e.g., a stub whose schedule relies on this does not throw).

🤖 Prompt for AI agents

Implement the fix for Bug 1: the `task` tool crashes with `this.isRunning is not
a function` in ACP/Zed mode because `initInteractiveScheduler()` copies the
scheduler's `schedule` method without preserving its receiver.

- In `packages/agents/src/core/subagentExecution.ts`, inside
`initInteractiveScheduler()`'s returned facade, replace the bare method
reference `schedule: scheduler.schedule` with an arrow-function closure that
calls `scheduler.schedule(request, signal)` using method-call syntax so `this`
resolves correctly at call time.
- Mirror the exact style already used in
`packages/cli/src/runtime/interactiveToolScheduler.ts` (`(request, signal) =>
instance.schedule(request, signal)`).
- Leave `awaitCompletedCalls` and `schedulerDispose` unchanged.
- Add a unit test extending `packages/agents/src/core/subagentExecution.test.ts`
that exercises the fallback branch of `initInteractiveScheduler()` (no
`schedulerFactory` provided) and asserts that invoking the returned facade's
`schedule(...)` correctly reaches the underlying scheduler instance's `schedule`
with the right receiver (e.g., a stub whose `schedule` relies on `this` does not
throw).

Phase 2: Make todo_pause stop the continuation loop (Bug 2)

Give AgenticLoop its own authoritative pause detection so ACP/Zed (which lacks the CLI's outer useTodoContinuation gate) stops looping when the model successfully calls todo_pause.

Task 1: Detect a successful `todo_pause` in `buildNextMessage()`

Short-circuit continuation when a successful todo_pause is among the completed tools.

• In packages/agents/src/core/agenticLoop/AgenticLoop.ts, before building/returning the normal continuation response in buildNextMessage(), add a check for a successful todo_pause among the completed agentTools.
• Replicate the success semantics established in TodoContinuationService.isSuccessfulTodoPauseResponse(): match the tool name case-insensitively against 'todo_pause' (prefer the shared TODO_PAUSE_TOOL constant from packages/tools/src/types/tool-names.ts rather than a hard-coded literal), and require the completed call to carry no error (status !== 'error' and no error/errorType on the response).
• On a successful pause, return { continueLoop: false, nextMessage: [] }, short-circuiting exactly like the existing all-cancelled branch. An errored/invalid todo_pause must fall through to the normal buildToolResponses/continue-loop behavior.

Task 2: Eagerly persist tool history on the pause path

Ensure the tool-call/response history is recorded even though there is no subsequent model turn to carry it.

• Since the successful-pause branch stops the loop, record the completed tools' history before returning, using the existing history-writing helper in packages/agents/src/core/loopHelpers.ts (the same mechanism recordCancelledToolHistory forwards to).
• Because recordCompletedToolHistory is currently private, expose it for this use — either export it directly or add a small exported wrapper analogous to recordCancelledToolHistory — and await it in buildNextMessage()'s pause branch so history is persisted before the loop ends.

Task 3: Add unit coverage for pause vs. non-pause behavior

Lock in the new continuation semantics at the AgenticLoop layer.

• Add tests (under packages/agents/src/core/agenticLoop/__tests__/) asserting that: a successful todo_pause completed tool yields continueLoop: false and triggers history recording; an errored todo_pause still yields continueLoop: true (normal behavior); and non-todo_pause successful tools are unaffected.

🤖 Prompt for AI agents

Implement the fix for Bug 2: `todo_pause` fails to stop the agent continuation
loop because `AgenticLoop.buildNextMessage()` never special-cases a successful
`todo_pause` call.

- In `packages/agents/src/core/agenticLoop/AgenticLoop.ts`, before
building/returning the normal continuation response in `buildNextMessage()`, add
a check for a successful `todo_pause` among the completed `agentTools`.
- Replicate the success semantics from
`TodoContinuationService.isSuccessfulTodoPauseResponse()`: match the tool name
case-insensitively against `'todo_pause'` (prefer the shared `TODO_PAUSE_TOOL`
constant from `packages/tools/src/types/tool-names.ts` over a hard-coded
literal), and require the completed call to have no error (`status !== 'error'`
and no `error`/`errorType` on the response).
- On a successful pause, return `{ continueLoop: false, nextMessage: [] }`,
short-circuiting exactly like the existing all-cancelled branch. An
errored/invalid `todo_pause` must fall through to the normal
`buildToolResponses`/continue-loop behavior.
- Since this branch stops the loop, record the completed tools' history before
returning using the existing history-writing helper in
`packages/agents/src/core/loopHelpers.ts` (the same mechanism
`recordCancelledToolHistory` forwards to). Because `recordCompletedToolHistory`
is currently private, expose it (export directly or add a small exported wrapper
analogous to `recordCancelledToolHistory`) and await it in the pause branch so
history is persisted before the loop ends.
- Add tests under `packages/agents/src/core/agenticLoop/__tests__/` asserting: a
successful `todo_pause` completed tool yields `continueLoop: false` and triggers
history recording; an errored `todo_pause` still yields `continueLoop: true`;
non-`todo_pause` successful tools are unaffected.

Phase 3: Reproduction and verification tooling

Provide the cross-platform script referenced by the ticket to reproduce both bugs and verify the fixes end-to-end in ACP mode.

Create `scripts/test-acp-zed-bugs.mjs`

Add the reproduction/verification harness (the file does not currently exist in the repo).

• Create scripts/test-acp-zed-bugs.mjs that spawns the llxprt-code process in --experimental-acp mode, performs the ACP handshake, and accepts a --profile <profile-name> argument.
• Send a prompt that invokes the task tool (to confirm Bug 1 no longer produces this.isRunning is not a function) and a prompt that triggers todo_pause (to confirm Bug 2 no longer loops/times out), plus a normal prompt as a control.
• Implement it in a cross-platform manner (Windows/macOS/Linux), following conventions from the existing scripts/test-acp-integration.mjs for process spawning and ACP message framing.

🤖 Prompt for AI agents

Create the reproduction/verification script referenced by the ticket.

- Create `scripts/test-acp-zed-bugs.mjs` that spawns the llxprt-code process in
`--experimental-acp` mode, performs the ACP handshake, and accepts a `--profile
<profile-name>` argument.
- Send a prompt that invokes the `task` tool (to confirm Bug 1 no longer
produces `this.isRunning is not a function`) and a prompt that triggers
`todo_pause` (to confirm Bug 2 no longer loops/times out), plus a normal prompt
as a control.
- Implement the script in a cross-platform manner (Windows/macOS/Linux),
following conventions from the existing `scripts/test-acp-integration.mjs` for
process spawning and ACP message framing.

Research

The agent loop lives in packages/agents/src/core. AgenticLoop.buildNextMessage() (in agenticLoop/AgenticLoop.ts) decides whether the loop continues after a batch of tool calls completes; it classifies completed tools, short-circuits on all-cancelled batches, and otherwise builds tool-response parts and continues. Continuation/pause history helpers live in loopHelpers.ts (including the private recordCompletedToolHistory and its exported wrapper recordCancelledToolHistory). Subagent scheduling is set up in subagentExecution.ts via initInteractiveScheduler(), which either uses a registered schedulerFactory (CLI-only) or falls back to Config.getOrCreateScheduler() (the path ACP/Zed always takes). The canonical correct closure pattern already exists in packages/cli/src/runtime/interactiveToolScheduler.ts. The todo_pause tool name is 'todo_pause' (constant TODO_PAUSE_TOOL in packages/tools/src/types/tool-names.ts; TodoPause.Name in the tool), and the authoritative success-detection pattern lives in TodoContinuationService.isSuccessfulTodoPauseResponse() (inspects response toolName case-insensitively and requires error/errorType to be undefined).

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the fix for Bug 1: the `task` tool crashes with `this.isRunning is not
a function` in ACP/Zed mode because `initInteractiveScheduler()` copies the
scheduler's `schedule` method without preserving its receiver.

- In `packages/agents/src/core/subagentExecution.ts`, inside
`initInteractiveScheduler()`'s returned facade, replace the bare method
reference `schedule: scheduler.schedule` with an arrow-function closure that
calls `scheduler.schedule(request, signal)` using method-call syntax so `this`
resolves correctly at call time.
- Mirror the exact style already used in
`packages/cli/src/runtime/interactiveToolScheduler.ts` (`(request, signal) =>
instance.schedule(request, signal)`).
- Leave `awaitCompletedCalls` and `schedulerDispose` unchanged.
- Add a unit test extending `packages/agents/src/core/subagentExecution.test.ts`
that exercises the fallback branch of `initInteractiveScheduler()` (no
`schedulerFactory` provided) and asserts that invoking the returned facade's
`schedule(...)` correctly reaches the underlying scheduler instance's `schedule`
with the right receiver (e.g., a stub whose `schedule` relies on `this` does not
throw).
===============================================================================

Task: 2

Implement the fix for Bug 2: `todo_pause` fails to stop the agent continuation
loop because `AgenticLoop.buildNextMessage()` never special-cases a successful
`todo_pause` call.

- In `packages/agents/src/core/agenticLoop/AgenticLoop.ts`, before
building/returning the normal continuation response in `buildNextMessage()`, add
a check for a successful `todo_pause` among the completed `agentTools`.
- Replicate the success semantics from
`TodoContinuationService.isSuccessfulTodoPauseResponse()`: match the tool name
case-insensitively against `'todo_pause'` (prefer the shared `TODO_PAUSE_TOOL`
constant from `packages/tools/src/types/tool-names.ts` over a hard-coded
literal), and require the completed call to have no error (`status !== 'error'`
and no `error`/`errorType` on the response).
- On a successful pause, return `{ continueLoop: false, nextMessage: [] }`,
short-circuiting exactly like the existing all-cancelled branch. An
errored/invalid `todo_pause` must fall through to the normal
`buildToolResponses`/continue-loop behavior.
- Since this branch stops the loop, record the completed tools' history before
returning using the existing history-writing helper in
`packages/agents/src/core/loopHelpers.ts` (the same mechanism
`recordCancelledToolHistory` forwards to). Because `recordCompletedToolHistory`
is currently private, expose it (export directly or add a small exported wrapper
analogous to `recordCancelledToolHistory`) and await it in the pause branch so
history is persisted before the loop ends.
- Add tests under `packages/agents/src/core/agenticLoop/__tests__/` asserting: a
successful `todo_pause` completed tool yields `continueLoop: false` and triggers
history recording; an errored `todo_pause` still yields `continueLoop: true`;
non-`todo_pause` successful tools are unaffected.
===============================================================================

Task: 3

Create the reproduction/verification script referenced by the ticket.

- Create `scripts/test-acp-zed-bugs.mjs` that spawns the llxprt-code process in
`--experimental-acp` mode, performs the ACP handshake, and accepts a `--profile
<profile-name>` argument.
- Send a prompt that invokes the `task` tool (to confirm Bug 1 no longer
produces `this.isRunning is not a function`) and a prompt that triggers
`todo_pause` (to confirm Bug 2 no longer loops/times out), plus a normal prompt
as a control.
- Implement the script in a cross-platform manner (Windows/macOS/Linux),
following conventions from the existing `scripts/test-acp-integration.mjs` for
process spawning and ACP message framing.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!