claude-code-cli: async_bash followUp notifications ingested as user prompts, triggering autonomous turns in interactive mode

[curtiswang96]

Problem

In interactive mode with the claude-code-cli provider, async_bash job completion notifications delivered via deliverAs:"followUp" are treated as the user's next instruction. The agent autonomously acts on the job output without any user prompt — in this case, immediately launching into code fixes the user had not yet approved, and visually pushing the prior response out of the window.

Root Cause

Two defects combine to produce the failure:

Defect 1 — extractLastUserPrompt in stream-adapter.ts ingests followUp messages as user prompts

File: src/resources/extensions/claude-code-cli/stream-adapter.ts (~line 80, extractLastUserPrompt)

When pi.sendMessage({deliverAs:"followUp"}) appends an async_job_result to pi's context, it lands as a user-role message. extractLastUserPrompt iterates backwards through context.messages and returns the first role:"user" message — which is now the job result. That string ("**Background job done: bg_e7c23baa**…\n\n=== live play ===\n\"started\"\n…") becomes the Claude Code SDK's prompt. The SDK runs a new full turn, and the agent acts on the job output as if the user requested it.

// Current — no guard for followUp/custom messages
function extractLastUserPrompt(context: Context): string {
    for (let i = context.messages.length - 1; i >= 0; i--) {
        const msg = context.messages[i];
        if (msg.role === "user") {
            // Returns job result content as the SDK prompt ← BUG
            if (typeof msg.content === "string") return msg.content;
            ...
        }
    }
    return "";
}

Fix: Skip messages with customType === "async_job_result" (or any message flagged as a followUp) when walking backwards:

function extractLastUserPrompt(context: Context): string {
    for (let i = context.messages.length - 1; i >= 0; i--) {
        const msg = context.messages[i];
        if (msg.role === "user") {
            // Skip follow-up notifications — informational only, not user instructions
            if ((msg as any).customType === "async_job_result") continue;
            if ((msg as any).isFollowUp === true) continue;
            if (typeof msg.content === "string") return msg.content;
            ...
        }
    }
    return "";
}

Defect 2 — No interactive-mode equivalent of clearQueue() for claude-code-cli sessions

File: src/resources/extensions/gsd/auto/run-unit.ts (lines ~121–133)

Auto-mode calls clearQueue() after each unit completes to discard pending followUp messages. Interactive mode has no such call. With native pi providers this is tolerable because deliverAs:"followUp" does not trigger a new turn when idle. With the claude-code-cli provider the followUp becomes the prompt on the next turn (Defect 1), so there is no safe idle state — every job completion that finishes after the agent's response will cause an autonomous turn.

Expected Behavior

• async_job_result followUp messages should display in the TUI but never become the Claude Code SDK prompt.
• The agent should remain idle after delivering a response; job completions should not trigger autonomous follow-up turns in interactive mode.
• The fix in async_bash job results trigger spurious LLM turns after agent completion #875 (deliverAs:"followUp") should apply correctly across all providers, including claude-code-cli.

Environment

• GSD version: 2.58.0
• Provider: claude-code-cli (via @anthropic-ai/claude-agent-sdk)
• Mode: interactive (non-auto-mode)

Reproduction Context

1. In an interactive session with the claude-code-cli provider, launch 4+ parallel async_bash jobs.
2. Agent produces a response (turn ends).
3. Background jobs complete → onJobComplete fires → pi.sendMessage({deliverAs:"followUp"}) queues results.
4. FollowUp messages appear in TUI, pushing prior response out of view.
5. On the next conversation cycle, extractLastUserPrompt returns the last job result string as the user's instruction.
6. Claude Code SDK runs a new turn treating job output as a user prompt.
7. Agent acts autonomously on the results (in this case, immediately began implementing code fixes before the user had reviewed the audit findings).

Forensic Evidence

• 4 async_bash jobs started during an audit (bg_fb7d16ae, bg_e7c23baa, bg_d3fe95de, bg_ee6d8891).
• Agent gave a complete audit response, then job results arrived one by one.
• Each result (**Background job done: bg_e7c23baa** (test live viewport controls, 1.5s)\n\n=== live play ===\n"started"\n…) appeared as a new user-turn prompt.
• Agent acted on results without user instruction, launching into code fixes.

Prior Art

• async_bash job results trigger spurious LLM turns after agent completion #875 (closed) — fixed triggerTurn:true → deliverAs:"followUp" for native providers. Does not cover the claude-code-cli path where followUps become SDK prompts via extractLastUserPrompt.
• Auto-mode: trailing async_job_result notifications delay unit completion and waste tokens #1642 (closed) — fixed auto-mode via clearQueue() in run-unit.ts. Interactive mode has no equivalent.

---

Auto-generated by /gsd forensics

[Kile-Thomson]

Confirming this affects native pi provider too, not just claude-code-cli.

We're seeing the same stale echo problem in both CLI (gsd headless) and interactive mode with the native provider. The agent spawns multiple async_bash jobs during a task, consumes their results via await_job, completes the turn — then each un-suppressed follow-up triggers a new LLM turn where the model responds with:

Already consumed during execution — that was the grep for the Enrollment model line number. Task T01 is complete.
Already consumed during execution. Task T01 is complete.
Already consumed during execution. Task T01 is complete.

5-8 of these per task in auto-mode is typical.

The awaited flag doesn't cover the common case

The queueMicrotask deferral in deliverResult() (#2762) only works when await_job is actively waiting at the moment the job completes. It doesn't cover:

1. Fast jobs that complete before await_job is called — follow-up fires immediately, awaited is never set
2. Agent awaits job A while jobs B/C complete in the background — only A gets awaited = true
3. await_job with no IDs — only catches currently-running jobs, not already-completed ones whose follow-ups already shipped
4. Fire-and-forget pattern (the recommended "continue working, results arrive as follow-up") — every completed job produces a follow-up

Test file

I wrote a test suite against AsyncJobManager + createAwaitTool that demonstrates all four scenarios. All 6 tests pass against current main (7839909), confirming the behavior:

stale-echo.test.ts (click to expand)

import test from "node:test";
import assert from "node:assert/strict";
import { AsyncJobManager } from "./job-manager.ts";
import { createAwaitTool } from "./await-tool.ts";

const noopSignal = new AbortController().signal;

function getTextFromResult(result: { content: Array<{ type: string; text?: string }> }): string {
	return result.content.map((c) => c.text ?? "").join("\n");
}

test("awaiting one job does not suppress follow-ups for other completed jobs", async () => {
	const followUps: string[] = [];
	const manager = new AsyncJobManager({
		onJobComplete: (job) => {
			if (!job.awaited) followUps.push(job.id);
		},
	});
	const tool = createAwaitTool(() => manager);

	const jobA = manager.register("bash", "job-A", async () => "result A");
	const jobB = manager.register("bash", "job-B", async () => "result B");
	const jobC = manager.register("bash", "job-C", async () => "result C");

	await manager.getJob(jobA)!.promise;
	await manager.getJob(jobB)!.promise;
	await manager.getJob(jobC)!.promise;
	await new Promise((r) => setTimeout(r, 50));

	assert.equal(followUps.length, 3, "All 3 unawaited jobs should trigger follow-ups");
	followUps.length = 0;

	await tool.execute("tc1", { jobs: [jobA] }, noopSignal, () => {}, undefined as never);

	assert.equal(manager.getJob(jobA)!.awaited, true);
	assert.equal(manager.getJob(jobB)!.awaited, undefined);
	assert.equal(manager.getJob(jobC)!.awaited, undefined);

	manager.shutdown();
});

test("awaiting all jobs before completion suppresses all follow-ups", async () => {
	const followUps: string[] = [];
	const manager = new AsyncJobManager({
		onJobComplete: (job) => {
			if (!job.awaited) followUps.push(job.id);
		},
	});
	const tool = createAwaitTool(() => manager);

	const jobA = manager.register("bash", "job-A", async () => {
		return new Promise<string>((r) => setTimeout(() => r("A"), 50));
	});
	const jobB = manager.register("bash", "job-B", async () => {
		return new Promise<string>((r) => setTimeout(() => r("B"), 50));
	});
	const jobC = manager.register("bash", "job-C", async () => {
		return new Promise<string>((r) => setTimeout(() => r("C"), 50));
	});

	await tool.execute("tc2", { jobs: [jobA, jobB, jobC] }, noopSignal, () => {}, undefined as never);
	await new Promise((r) => setTimeout(r, 50));

	assert.equal(followUps.length, 0);

	manager.shutdown();
});

test("fire-and-forget jobs all produce follow-ups (the echo source)", async () => {
	const followUps: string[] = [];
	const manager = new AsyncJobManager({
		onJobComplete: (job) => {
			if (!job.awaited) followUps.push(job.id);
		},
	});

	const ids: string[] = [];
	for (let i = 0; i < 5; i++) {
		ids.push(manager.register("bash", `job-${i}`, async () => `result ${i}`));
	}

	for (const id of ids) {
		await manager.getJob(id)!.promise;
	}
	await new Promise((r) => setTimeout(r, 50));

	assert.equal(followUps.length, 5);

	manager.shutdown();
});

test("job completing while agent awaits a different job still produces follow-up", async () => {
	const followUps: string[] = [];
	const manager = new AsyncJobManager({
		onJobComplete: (job) => {
			if (!job.awaited) followUps.push(job.id);
		},
	});
	const tool = createAwaitTool(() => manager);

	const jobA = manager.register("bash", "slow-job", async () => {
		return new Promise<string>((r) => setTimeout(() => r("slow result"), 200));
	});
	const jobB = manager.register("bash", "fast-job", async () => {
		return new Promise<string>((r) => setTimeout(() => r("fast result"), 50));
	});

	await tool.execute("tc4", { jobs: [jobA] }, noopSignal, () => {}, undefined as never);
	await new Promise((r) => setTimeout(r, 50));

	assert.equal(manager.getJob(jobA)!.awaited, true);
	assert.equal(followUps.filter((id) => id === jobB).length, 1);

	manager.shutdown();
});

test("queueMicrotask ensures awaited flag is set before onJobComplete fires", async () => {
	let deliveryOrder: string[] = [];
	const manager = new AsyncJobManager({
		onJobComplete: (job) => {
			deliveryOrder.push(`callback:${job.id}:awaited=${job.awaited}`);
		},
	});
	const tool = createAwaitTool(() => manager);

	const jobId = manager.register("bash", "timing-test", async () => {
		return new Promise<string>((r) => setTimeout(() => r("done"), 10));
	});

	await tool.execute("tc5", { jobs: [jobId] }, noopSignal, () => {}, undefined as never);
	await new Promise((r) => setTimeout(r, 50));

	const entry = deliveryOrder.find((e) => e.includes(jobId));
	assert.ok(entry);
	assert.match(entry!, /awaited=true/);

	manager.shutdown();
});

test("await_job with no IDs only marks currently-running jobs as awaited", async () => {
	const followUps: string[] = [];
	const manager = new AsyncJobManager({
		onJobComplete: (job) => {
			if (!job.awaited) followUps.push(job.id);
		},
	});
	const tool = createAwaitTool(() => manager);

	const jobA = manager.register("bash", "already-done", async () => "done");
	await manager.getJob(jobA)!.promise;
	await new Promise((r) => setTimeout(r, 50));

	assert.equal(followUps.length, 1);
	followUps.length = 0;

	const jobB = manager.register("bash", "still-running", async () => {
		return new Promise<string>((r) => setTimeout(() => r("B done"), 100));
	});

	await tool.execute("tc6", {}, noopSignal, () => {}, undefined as never);
	await new Promise((r) => setTimeout(r, 50));

	assert.equal(followUps.length, 0);
	assert.equal(manager.getJob(jobB)!.awaited, true);
	assert.equal(manager.getJob(jobA)!.awaited, undefined);

	manager.shutdown();
});

Suggestion

The fix in this issue's Defect 1 (skipping async_job_result in extractLastUserPrompt) addresses the claude-code-cli path, but the core problem is in job-manager.ts / index.ts — onJobComplete delivers follow-ups that are already stale regardless of provider. Deferring delivery until the current turn ends (and checking awaited at that point) would fix it across all providers.

[jeremymcs]

This issue has two open PRs that both claim to fix it:

• PR fix(claude-code-cli): skip async_job_result followUps in extractLastUserPrompt #3219 (fix(claude-code-cli): skip async_job_result followUps in extractLastUserPrompt)
• PR fix(claude-code-cli): ignore informational follow-up prompts #3415 (fix(claude-code-cli): ignore informational follow-up prompts)

A maintainer should designate which PR is the canonical fix. The other should be closed or redirected to avoid duplicate work landing. This issue will close automatically once the designated PR merges.

[Tibsfox]

Several auto-mode stuck-loop and dispatch fixes from the recent batch address related root causes:

• PR fix(gsd): cap run-uat dispatch attempts to prevent infinite replay loop #3686 — run-uat dispatch cap (per-slice counter, max 3 attempts)
• PR fix(gsd): force re-validation when verdict is needs-remediation #3670 — needs-remediation revalidation breaks completing-milestone deadlock
• PR fix(gsd): auto-remediate stale slice DB status when SUMMARY exists #3673 — auto-remediate stale slice status breaks complete-slice re-dispatch
• PR fix(gsd): set slice sequence at all three insertion sites #3697 — slice sequence prevents positional ordering deadlocks
• PR fix(gsd): stop renderAllProjections from overwriting authoritative PLAN.md #3676 — renderAllProjections no longer overwrites PLAN.md
• PR fix(gsd): prompt ordering, correct tools, crash guard, compaction fix #3696 — session_before_compact no longer blocks when paused

If this issue persists after those merges, the remaining stuck-loop path should be more specific and easier to diagnose.

[jeremymcs]

PR #3219 has merge conflicts that need to be resolved before this issue can close.

Hey @stefanriegel — your branch has conflicts with main. Here's how to resolve them:

git fetch origin
git checkout fix/async-bash-followup-skip
git merge origin/main
# resolve conflicts, then:
git add .
git commit
git push

Once the conflicts are resolved and CI is green, this will be ready to merge. Give us a shout if you get stuck!

[jeremymcs]

This project has made rapid advancements since this was posted. If you're still experiencing this issue, please make sure you're on the latest version and re-open.