@agentuity/opencode 1.0.19 → 1.0.20

package/src/agents/lead.ts

@@ -19,7 +19,7 @@ Then proceed with the appropriate action. This prevents misclassifying requests.
 - **Quality gatekeeper.** Not: Cloud operator.
 - **Context coordinator.** Not: Test runner.
 
-**Golden Rule**: If it involves writing code, editing files, running commands, searching codebases, or gathering information via research — default to delegating it. Your job is to think, plan, coordinate, and decide. You CAN do lightweight research when working solo on simple tasks, but once you've delegated work to background agents, commit fully to the orchestration role.
+**Golden Rule**: If it involves writing code, editing files, running commands, searching codebases, or gathering information via research — default to delegating it. Your job is to think, plan, coordinate, and decide. You CAN do lightweight research when working solo on simple tasks, but once you've delegated work, commit fully to the orchestration role.
 
 ## Delegation Decision Guide
 
@@ -464,51 +464,14 @@ Use Open Code's Task tool to delegate work to subagents:
 - \`@Agentuity Coder Expert\` — for Agentuity CLI commands and cloud questions
 - \`@Agentuity Coder Runner\` — for running lint/build/test/typecheck/format commands (structured results)
 
-## Background Tasks (Parallel Execution)
+## Parallel Delegation
 
-You have access to the \`agentuity_background_task\` tool for running agents in parallel without blocking.
-
-**CRITICAL: Use \`agentuity_background_task\` instead of \`task\` when:**
-- Launching multiple independent tasks (e.g., reviewing multiple packages)
-- Tasks that can run concurrently without dependencies
-- You want to continue working while agents run in parallel
-- The user asks for "parallel", "background", or "concurrent" execution
-
-**How to use \`agentuity_background_task\`:**
-\`\`\`
-agentuity_background_task({
-  agent: "scout",  // scout, builder, reviewer, memory, expert
-  task: "Research security vulnerabilities for package X",
-  description: "Security review: package X"  // optional short description
-})
-// Returns: { taskId: "bg_xxx", status: "pending" }
-\`\`\`
-
-**Checking results:**
-\`\`\`
-agentuity_background_output({ task_id: "bg_xxx" })
-// Returns: { taskId, status, result, error }
-\`\`\`
-
-**Cancelling:**
-\`\`\`
-agentuity_background_cancel({ task_id: "bg_xxx" })
-\`\`\`
-
-**Session Dashboard (Lead-of-Leads Monitoring):**
-\`\`\`
-agentuity_session_dashboard({ session_id: "ses_xxx" })
-// Returns: hierarchy of child sessions with status, costs, active tools, and health summary
-\`\`\`
-
-Use \`agentuity_session_dashboard\` when orchestrating Lead-of-Leads to get a full view of all child sessions, their status, costs, and what they're currently doing — without needing to inspect each task individually.
+Use the \`task\` tool for ALL delegation. For parallel work, issue multiple \`task\` calls in a single response — OpenCode runs them concurrently and returns results inline.
 
 **Example - Parallel Security Review:**
 When asked to review multiple packages for security:
-1. Launch \`agentuity_background_task\` for each package with Scout
-2. Report the task IDs and descriptions to the user, then STOP
-3. Wait for \`[BACKGROUND TASK COMPLETED]\` notifications (event-driven, no polling)
-4. Synthesize results after all notifications arrive
+1. Launch multiple \`task\` calls for each package with Scout
+2. Synthesize results after all task responses arrive
 
 ## Orchestration Patterns
 
@@ -519,9 +482,9 @@ Task → Agent → Result
 \`\`\`
 
 ### FanOut (Parallel)
-Launch multiple independent tasks in parallel. **Use \`agentuity_background_task\` tool.**
+Launch multiple independent tasks in parallel by issuing multiple \`task\` calls in a single response.
 \`\`\`
-agentuity_background_task(A) + agentuity_background_task(B) + agentuity_background_task(C) → Combine Results
+task(A) + task(B) + task(C) → Combine Results
 \`\`\`
 
 ### Pipeline
@@ -555,7 +518,7 @@ Task → Agent A → Agent B → Agent C → Final Result
 - **Phase 3: Verify** — Agent(s): Reviewer. Action: Verify fix, check for regressions. Decision point: If regressions found → iterate with Builder.
 
 ### Research Workflow
-- **Phase 1: Explore** — Agent(s): Scout (parallel). Action: Investigate multiple areas. Decision point: If findings conflict → investigate further.
+- **Phase 1: Explore** — Agent(s): Scout. Action: Investigate multiple areas (use multiple \`task\` calls for parallel exploration when helpful). Decision point: If findings conflict → investigate further.
 - **Phase 2: Synthesize** — Agent(s): Lead. Action: Combine findings, form recommendations. Decision point: If gaps remain → send Scout for targeted follow-up.
 - **Phase 3: Store** — Agent(s): Memory. Action: Preserve key insights. Decision point: Always store actionable insights.
 
@@ -611,7 +574,7 @@ When the user signals they want autonomous, aggressive execution, enter **Ultraw
 
 **Ultrawork Mode behavior:**
 1. **Micro-plan first** — Create a quick 5-10 bullet plan (don't skip planning entirely)
-2. **Aggressive delegation** — Use FanOut pattern, run Scout in parallel for discovery
+2. **Aggressive delegation** — Use FanOut pattern with multiple \`task\` calls when parallel discovery helps
 3. **Auto-continue** — Don't stop to ask permission; keep iterating until truly done
 4. **Verification gates** — Still require Reviewer for non-trivial changes
 5. **Memory checkpoints** — Store progress frequently for recovery
@@ -633,71 +596,14 @@ When the user signals they want autonomous, aggressive execution, enter **Ultraw
 - **Over-parallelizing:** Dependencies cause conflicts and wasted work → Sequence dependent tasks, parallelize only independent.
 - **Skipping Scout:** Acting without understanding leads to wrong solutions → Always gather context before planning.
 - **Running build/test directly:** Wastes context with raw output, misses structured errors → Delegate to Runner for structured results.
-- **Doing background work yourself:** Duplicates work, wastes tokens, confuses results → Wait for [BACKGROUND TASK COMPLETED] notifications.
-- **Cancelling tasks that are slow:** Slow ≠ stuck. Scout tasks take 3–8 minutes normally → Check progress first; only cancel on genuine stall.
-
-## CRITICAL: Background Task Patience
-
-### Monitor is auto-launched — you do not manage it
-
-When you launch background tasks via \`agentuity_background_task\`, **a Monitor agent is automatically started** to watch all tasks for your session. You do not need to spawn it manually. Monitor uses \`agentuity_session_dashboard\` scoped to your session ID — it sees your child tasks only.
-
-**Your role while background tasks run:**
-1. **Report what you launched** — List task IDs and descriptions, then STOP
-2. **Wait for Monitor's consolidated report** — Monitor will push \`[ALL BACKGROUND TASKS COMPLETE]\` when all work tasks finish
-3. **Wait for individual \`[BACKGROUND TASK COMPLETED]\` notifications** — These fire event-driven as each task finishes
-4. **Process results** — Use \`agentuity_background_output\` to retrieve full results after notification
-
-**You do NOT need to poll.** Monitor is watching. The events are real-time. Polling wastes your context.
-
-### Tool restrictions while waiting
-
-You are in **orchestration-only mode** after launching background tasks. Do NOT use:
-- \`webfetch\` — do not fetch URLs
-- \`grep\` / \`glob\` — do not search the codebase
-- \`read\` — do not read source files for research
-- \`bash\` — do not run exploratory commands
-
-These tools fill your context with content you've already delegated to background agents. One webfetch response can consume 5–15% of your context.
-
-**You CAN:**
-- Answer user questions about current progress
-- Update todo list items
-- Use extended thinking (no tool calls) to reason about how you'll combine results when they arrive
-
-### If you feel the urge to check on a task
-
-Before doing anything, call \`agentuity_background_output\` once and read the \`progress\` field:
-
-\`\`\`json
-{
-  "status": "running",
-  "progress": {
-    "toolCalls": 21,
-    "lastTool": "read",
-    "lastToolSec": 44,
-    "activeTools": 1
-  }
-}
-\`\`\`
-
-- \`toolCalls > 0\` and \`lastToolSec < 300\` → **STILL WORKING. Do not intervene.**
-- \`lastToolSec > 300\` AND \`activeTools === 0\` → Task may be genuinely stuck. Use \`agentuity_background_inspect\` for a full view, then decide.
-
-**A Scout reading a large codebase takes 3–8 minutes. That is completely normal.**
-
-### Never cancel based on elapsed time alone
-
-Cancelling a nearly-done task wastes all its work and forces you to do it yourself — filling your context with raw tool output instead of a clean Scout report. Always check \`progress\` before cancelling.
 
 ## Context Budget Awareness
 
 Every tool call output consumes context you need later for processing results. A single webfetch can be 5–15% of your window. Three unnecessary fetches while waiting can waste 30–45% — leaving you unable to properly synthesize the Scout reports you're waiting for.
 
 **Before using any research tool, ask:**
-1. "Is a background agent already getting this?" → If yes, WAIT.
-2. "Do I need this RIGHT NOW for a decision?" → If no, WAIT.
-3. "Will this output be large?" → If yes, delegate it.
+1. "Do I need this RIGHT NOW for a decision?" → If no, WAIT.
+2. "Will this output be large?" → If yes, delegate it.
 
 ## Task Completion: Memorialize the Session
 
@@ -1202,7 +1108,7 @@ When a task is too large or has independent workstreams that can run in parallel
 - Large tasks with clear sequential order (do step 1, then step 2, then step 3)
 - Work that requires tight coordination between parts
 
-**Rule of thumb:** Lead-of-Leads is for explicitly large, parallelizable work OR when the user explicitly asks for multiple big background tasks. Default to sequential execution unless parallelism is clearly beneficial.
+**Rule of thumb:** Lead-of-Leads is for explicitly large, parallelizable work OR when the user explicitly asks for parallel execution. Default to sequential execution unless parallelism is clearly beneficial.
 
 #### Lead-of-Leads Workflow
 
@@ -1222,23 +1128,19 @@ Product will structure the PRD with:
 ]
 \`\`\`
 
-**2. Spawn Child Leads via Background Tasks**
+**2. Spawn Child Leads via the \`task\` Tool**
+
+Use the \`task\` tool to spawn child Leads. For parallel work, issue multiple \`task\` calls in a single response:
 
-Use \`agentuity_background_task\` to spawn child Leads:
+\`\`\`
+@Agentuity Coder Lead
 
-\`\`\`typescript
-// Spawn child Lead for auth workstream
-agentuity_background_task({
-  agent: "lead",
-  task: \`[CADENCE MODE] [CHILD LEAD]
+[CADENCE MODE] [CHILD LEAD]
 Parent Loop: {your loopId}
 PRD Key: project:{label}:prd
 Workstream: Auth Module
 
-Implement the authentication module. Claim your workstream in the PRD, 
-work autonomously, and mark complete when done.\`,
-  description: "Child Lead: Auth Module"
-})
+Implement the authentication module. Claim your workstream in the PRD, work autonomously, and mark complete when done.
 \`\`\`
 
 **3. Child Lead Behavior**
@@ -1259,26 +1161,10 @@ agentuity cloud kv get agentuity-opencode-memory "project:{label}:prd" --json --
 # Ask Product: "Claim workstream 'Auth Module' for session {sessionId}"
 \`\`\`
 
-**4. Wait for Event-Driven Notifications**
-
-After spawning child Leads, you will automatically receive notifications as each task completes:
-
-- \`[BACKGROUND TASK COMPLETED]\` — fires for each task as it finishes
-- A Monitor agent is auto-launched to provide a consolidated \`[ALL BACKGROUND TASKS COMPLETE]\` report when all tasks are done
-
-**You do NOT need to spawn a Monitor manually or poll.** The system handles this:
-- Event-driven notifications arrive in real-time as each child completes
-- The auto-launched Monitor watches all sibling tasks and sends a final summary
-- Keeps Lead's context clean (no polling loop exhausting context)
-- If Lead compacts, task references are preserved in context (injected by hooks)
-- Use \`agentuity_session_dashboard({ session_id: "<your_session_id>" })\` to check overall progress
-- Use \`agentuity_background_output({ task_id: "bg_xxx" })\` to retrieve results after a notification arrives
-- Use \`agentuity_background_inspect\` only if a task appears stuck (no activity for 5+ minutes)
-
-**5. Completion**
+**4. Completion**
 
 Parent Lead completes when:
-- All child task notifications have arrived (or Monitor sends consolidated report)
+- All child task results have returned
 - All workstreams in PRD show status "done"
 - Any integration/coordination work is complete
 
@@ -1289,15 +1175,10 @@ User: "Build the e-commerce checkout flow with auth, cart, and payments — do t
 
 You (Parent Lead):
 1. Ask Product to establish PRD with 3 workstreams
-2. Spawn 3 child Leads via background tasks:
-   - bg_auth: Auth workstream
-   - bg_cart: Cart workstream  
-   - bg_payments: Payments workstream
-3. Wait for [BACKGROUND TASK COMPLETED] notifications (auto-delivered for each)
-4. Monitor auto-launches to send [ALL BACKGROUND TASKS COMPLETE] when all finish
-5. Use agentuity_background_output to retrieve results after each notification
-6. Check PRD status, do integration work if needed
-7. Output <promise>DONE</promise>
+2. Spawn 3 child Leads using multiple task calls in one response
+3. Wait for each task result inline
+4. Check PRD status, do integration work if needed
+5. Output <promise>DONE</promise>
 \`\`\`
 
 #### Coordination Rules
@@ -1306,7 +1187,6 @@ You (Parent Lead):
 - **Product manages workstreams** — Ask Product to claim/update workstream status
 - **No direct child-to-child communication** — Coordinate through PRD
 - **Parent handles integration** — After children complete, parent does any glue work
-- **Notifications are automatic** — Each task sends [BACKGROUND TASK COMPLETED] on finish; Monitor auto-launches for consolidated reports
 - **Session dashboard** — Use \`agentuity_session_dashboard\` to get a unified view of all child session states, costs, and health without inspecting each task individually
 
 ### Context Management

package/src/agents/scout.ts

@@ -65,6 +65,18 @@ ALWAYS batch independent tool calls together. When you need to read multiple fil
 - **External API docs:** Use web fetch — official sources.
 - **Understanding file contents:** Use Read — full context.
 
+## Reading Large Files
+
+The Read tool returns up to 2000 lines by default. For files longer than that, it will indicate truncation. **Never re-read the same file from offset 0 when it was already truncated — that is a loop, not progress.**
+
+Rules for large files:
+1. **Check truncation first:** If read returns the full file (not truncated), you have everything — do not re-read it.
+2. **Paginate forward, not backward:** If truncated, use the offset parameter to continue from where you left off, not to restart. E.g. first call gets lines 1–2000, next call uses offset: 2001.
+3. **Use grep to avoid reading at all:** For specific symbols or patterns in large files, grep with a pattern is faster and cheaper than paginating through the whole file.
+4. **Check file size first:** If you need the whole file and it may be very long, use bash with wc -l first to check size, then decide whether to paginate or grep instead.
+5. **Never retry a completed read thinking it failed:** A completed status means the tool worked. If the content seems incomplete, the file is large — paginate forward with offset, do not retry from scratch.
+6. **Do not narrate perceived tool failures:** If a read returns content (even partial), it succeeded. Do not emit "tools are failing" or "let me try again" unless the tool returned an explicit error status.
+
 ### Documentation Source Priority
 
 **CRITICAL: Never hallucinate URLs.** If you don't know the exact URL path for agentuity.dev, say "check agentuity.dev for [topic]" instead of making up a URL. Use GitHub SDK repo URLs which are predictable and verifiable.
@@ -322,4 +334,8 @@ export const scoutAgent: AgentDefinition = {
 	},
 	// Scout uses default variant (speed over depth) and low temp for factual exploration
 	temperature: 0.0,
+	// Cap steps to prevent runaway read-loops on large files. 80 steps is ample for
+	// thorough research (parallel batching means 5-10 files per step) while breaking
+	// any infinite retry cycle before it burns significant context budget.
+	maxSteps: 80,
 };

package/src/config/loader.ts

@@ -2,7 +2,6 @@ import { homedir } from 'node:os';
 import { join } from 'node:path';
 import { YAML } from 'bun';
 import type { CoderConfig, SkillsConfig } from '../types';
-import type { BackgroundTaskConfig } from '../background/types';
 import { CoderConfigSchema } from '../types';
 import type { TmuxConfig } from '../tmux/types';
 import { MIN_PANE_WIDTH } from '../tmux/types';
@@ -17,13 +16,6 @@ interface CLICoderConfig {
 		mainPaneMinWidth?: number;
 		agentPaneMinWidth?: number;
 	};
-	background?: {
-		enabled?: boolean;
-		defaultConcurrency?: number;
-		staleTimeoutMs?: number;
-		providerConcurrency?: Record<string, number>;
-		modelConcurrency?: Record<string, number>;
-	};
 }
 
 interface CLIConfig {
@@ -104,7 +96,7 @@ export async function loadCoderConfig(): Promise<CoderConfig> {
 		const cliConfig = YAML.parse(content) as CLIConfig;
 
 		// Extract orgId from CLI config preferences
-		// Extract coder settings (tmux, background) from CLI config coder section
+		// Extract coder settings (tmux) from CLI config coder section
 		// Agent model overrides should be done via opencode.json
 		const coderConfig: CoderConfig = {
 			org: cliConfig.preferences?.orgId,
@@ -114,12 +106,6 @@ export async function loadCoderConfig(): Promise<CoderConfig> {
 						...cliConfig.coder.tmux,
 					}
 				: undefined,
-			background: cliConfig.coder?.background
-				? {
-						...DEFAULT_BACKGROUND_CONFIG,
-						...cliConfig.coder.background,
-					}
-				: undefined,
 		};
 
 		const result = CoderConfigSchema.safeParse(coderConfig);
@@ -144,14 +130,6 @@ const DEFAULT_BLOCKED_COMMANDS = [
 	'auth token', // Don't leak auth tokens
 ];
 
-const DEFAULT_BACKGROUND_CONFIG: BackgroundTaskConfig = {
-	enabled: true,
-	defaultConcurrency: 5,
-	staleTimeoutMs: 30 * 60 * 1000,
-	providerConcurrency: {},
-	modelConcurrency: {},
-};
-
 const DEFAULT_SKILLS_CONFIG: SkillsConfig = {
 	enabled: true,
 	paths: [],
@@ -175,7 +153,6 @@ export function getDefaultConfig(): CoderConfig {
 	return {
 		disabledMcps: [],
 		blockedCommands: DEFAULT_BLOCKED_COMMANDS,
-		background: DEFAULT_BACKGROUND_CONFIG,
 		skills: DEFAULT_SKILLS_CONFIG,
 		tmux: DEFAULT_TMUX_CONFIG,
 	};
@@ -186,32 +163,11 @@ export function mergeConfig(base: CoderConfig, override: CoderConfig): CoderConf
 		org: override.org ?? base.org,
 		disabledMcps: override.disabledMcps ?? base.disabledMcps,
 		blockedCommands: override.blockedCommands ?? base.blockedCommands,
-		background: mergeBackgroundConfig(base.background, override.background),
 		skills: mergeSkillsConfig(base.skills, override.skills),
 		tmux: mergeTmuxConfig(base.tmux, override.tmux),
 	};
 }
 
-function mergeBackgroundConfig(
-	base?: BackgroundTaskConfig,
-	override?: BackgroundTaskConfig
-): BackgroundTaskConfig | undefined {
-	if (!base && !override) return undefined;
-	return {
-		enabled: override?.enabled ?? base?.enabled ?? true,
-		defaultConcurrency: override?.defaultConcurrency ?? base?.defaultConcurrency ?? 5,
-		staleTimeoutMs: override?.staleTimeoutMs ?? base?.staleTimeoutMs ?? 30 * 60 * 1000,
-		providerConcurrency: {
-			...(base?.providerConcurrency ?? {}),
-			...(override?.providerConcurrency ?? {}),
-		},
-		modelConcurrency: {
-			...(base?.modelConcurrency ?? {}),
-			...(override?.modelConcurrency ?? {}),
-		},
-	};
-}
-
 function mergeSkillsConfig(base?: SkillsConfig, override?: SkillsConfig): SkillsConfig | undefined {
 	if (!base && !override) return undefined;
 	const paths = new Set([...(base?.paths ?? []), ...(override?.paths ?? [])]);

package/src/index.ts

@@ -13,7 +13,6 @@ export type {
 	AgentContext,
 	CoderTask,
 	CoderConfig,
-	BackgroundTaskConfig,
 	McpConfig,
 	TaskStatus,
 } from './types';

package/src/plugin/hooks/cadence.ts

@@ -1,6 +1,5 @@
 import type { PluginInput } from '@opencode-ai/plugin';
 import type { CoderConfig } from '../../types';
-import type { BackgroundManager } from '../../background';
 import type { OpenCodeDBReader, SessionTreeNode } from '../../sqlite';
 import type { CompactionStats } from '../../sqlite/types';
 import {
@@ -68,7 +67,6 @@ interface CadenceSessionState {
 export function createCadenceHooks(
 	ctx: PluginInput,
 	config: CoderConfig,
-	backgroundManager?: BackgroundManager,
 	dbReader?: OpenCodeDBReader,
 	lastUserMessages?: Map<string, string>
 ): CadenceHooks {
@@ -361,47 +359,21 @@ After compaction:
 3. Lead will continue the loop from iteration ${state.iteration}
 4. Use 5-Question Reboot to re-orient: Where am I? Where going? Goal? Learned? Done?`;
 
-			// 4. Build background tasks section
-			const tasks = backgroundManager?.getTasksByParent(sessionId) ?? [];
-			let backgroundSection: string | null = null;
-
-			if (tasks.length > 0) {
-				const taskList = tasks
-					.map(
-						(t) =>
-							`- **${t.id}**: ${t.description || 'No description'} (session: ${t.sessionId ?? 'pending'}, status: ${t.status})`
-					)
-					.join('\n');
-
-				backgroundSection = `## Active Background Tasks
-
-This session has ${tasks.length} background task(s) running in separate sessions:
-${taskList}
-
-**CRITICAL:** Task IDs and session IDs persist across compaction - these tasks are still running.
-Use \`agentuity_background_output({ task_id: "..." })\` to check their status.
-Use \`agentuity_session_dashboard({ session_id: "..." })\` to get a full session tree with status, costs, and health summary for Lead-of-Leads monitoring.
-
-**Tip:** A Monitor agent is auto-launched to watch these tasks. You will receive \`[BACKGROUND TASK COMPLETED]\` notifications as each task finishes, and \`[ALL BACKGROUND TASKS COMPLETE]\` when all are done. Use \`agentuity_session_dashboard\` for a unified progress view.`;
-			}
-
-			// 5. Build SQLite dashboard section
+			// 4. Build SQLite dashboard section
 			const dashboardSection = buildSqliteDashboardSummary(dbReader, sessionId);
 
-			// 6. Combine everything into the full prompt
+			// 5. Combine everything into the full prompt
 			const sections: string[] = [];
 			if (instructions) sections.push(instructions);
 			sections.push(cadenceStateSection);
-			if (backgroundSection) sections.push(backgroundSection);
 			if (planningState) sections.push(planningState);
 			if (imageDescs) sections.push(imageDescs);
 			if (toolSummaries) sections.push(toolSummaries);
 			if (dashboardSection) sections.push(dashboardSection);
 
-			// 7. Add diagnostics
+			// 6. Add diagnostics
 			const stats: CompactionStats = {
 				planningPhasesCount: countListItems(planningState),
-				backgroundTasksCount: tasks.length,
 				imageDescriptionsCount: countListItems(imageDescs),
 				toolCallSummariesCount: countListItems(toolSummaries),
 				estimatedTokens: Math.ceil(sections.join('\n\n').length / 4),
@@ -409,7 +381,7 @@ Use \`agentuity_session_dashboard({ session_id: "..." })\` to get a full session
 			const diagnostics = formatCompactionDiagnostics(stats);
 			if (diagnostics) sections.push(diagnostics);
 
-			// 8. Enforce token budget
+			// 7. Enforce token budget
 			let fullPrompt = sections.join('\n\n');
 			const estimatedTokens = Math.ceil(fullPrompt.length / 4);
 			if (maxTokens > 0 && estimatedTokens > maxTokens) {
@@ -425,24 +397,19 @@ Use \`agentuity_session_dashboard({ session_id: "..." })\` to get a full session
 				fullPrompt = trimmed.join('\n\n');
 			}
 
-			// 9. Set the full prompt or push to context
+			// 8. Set the full prompt or push to context
 			if (useCustomPrompt) {
 				output.prompt = fullPrompt;
 			} else {
 				output.context.push(fullPrompt);
 			}
 
-			// 10. Store pre-compaction snapshot to KV (fire-and-forget)
+			// 9. Store pre-compaction snapshot to KV (fire-and-forget)
 			if (useSnapshotToKV) {
 				storePreCompactionSnapshot(sessionId, {
 					timestamp: new Date().toISOString(),
 					sessionId,
 					planningState: planningState ? { raw: planningState } : undefined,
-					backgroundTasks: tasks.map((t) => ({
-						id: t.id,
-						description: t.description || 'No description',
-						status: t.status,
-					})),
 					cadenceState: state ? { ...state } : undefined,
 					branch,
 				}).catch(() => {}); // Fire and forget

package/src/plugin/hooks/compaction-utils.ts

@@ -70,13 +70,12 @@ export function buildCustomCompactionPrompt(mode: 'cadence' | 'regular'): string
 
 ## CRITICAL — Preserve These Verbatim
 1. The current task/objective (quote the user's original request exactly)
-2. All background task IDs (bg_xxx) with status, purpose, and session IDs
-3. Active planning state: current phase, completed phases, next steps, blockers
-4. ALL file paths being actively worked on (with role: created/modified/read)
-5. Key decisions made and their rationale
-6. Any corrections or gotchas discovered during the session
-7. Todo list state (what's done, in progress, pending)
-8. Descriptions of any images or attachments that appeared in conversation${cadenceSection}
+2. Active planning state: current phase, completed phases, next steps, blockers
+3. ALL file paths being actively worked on (with role: created/modified/read)
+4. Key decisions made and their rationale
+5. Any corrections or gotchas discovered during the session
+6. Todo list state (what's done, in progress, pending)
+7. Descriptions of any images or attachments that appeared in conversation${cadenceSection}
 
 ## Structure Your Summary As:
 
@@ -86,9 +85,6 @@ export function buildCustomCompactionPrompt(mode: 'cadence' | 'regular'): string
 ### Planning State
 [Phases with status. Include phase notes, not just titles.]
 
-### Background Tasks
-[bg_xxx: description → status (running/completed/errored). Include session IDs.]
-
 ### Key Context
 [Decisions, constraints, user preferences, corrections discovered]
 
@@ -104,7 +100,6 @@ export function buildCustomCompactionPrompt(mode: 'cadence' | 'regular'): string
 ## Rules
 - Use specific file paths, task IDs, phase names — NOT vague references.
 - State what tools returned, not just that they were called.
-- NEVER drop background task references — the agent MUST know what's still running.
 - Prefer completeness over brevity — this is the agent's entire working memory.`;
 }
 
@@ -267,7 +262,6 @@ export async function restoreCadenceStateFromKV(
 export function formatCompactionDiagnostics(stats: CompactionStats): string {
 	const parts: string[] = [];
 	if (stats.planningPhasesCount > 0) parts.push(`${stats.planningPhasesCount} planning phases`);
-	if (stats.backgroundTasksCount > 0) parts.push(`${stats.backgroundTasksCount} background tasks`);
 	if (stats.imageDescriptionsCount > 0) parts.push(`${stats.imageDescriptionsCount} image refs`);
 	if (stats.toolCallSummariesCount > 0) parts.push(`${stats.toolCallSummariesCount} tool calls`);
 

package/src/plugin/hooks/session-memory.ts

@@ -1,6 +1,5 @@
 import type { PluginInput } from '@opencode-ai/plugin';
 import type { CoderConfig } from '../../types';
-import type { BackgroundManager } from '../../background';
 import type { OpenCodeDBReader } from '../../sqlite';
 import type { CompactionStats } from '../../sqlite/types';
 import {
@@ -34,7 +33,6 @@ export interface SessionMemoryHooks {
 export function createSessionMemoryHooks(
 	ctx: PluginInput,
 	config: CoderConfig,
-	backgroundManager?: BackgroundManager,
 	dbReader?: OpenCodeDBReader
 ): SessionMemoryHooks {
 	const log = (msg: string) => {
@@ -188,40 +186,17 @@ After compaction:
 2. If planning is active, Memory should update planning.progress with this compaction
 3. Memory will apply inline reasoning if significant patterns/corrections emerged`;
 
-			// 4. Build background tasks section
-			const tasks = backgroundManager?.getTasksByParent(sessionId) ?? [];
-			let backgroundSection: string | null = null;
-
-			if (tasks.length > 0) {
-				const taskList = tasks
-					.map(
-						(t) =>
-							`- **${t.id}**: ${t.description || 'No description'} (session: ${t.sessionId ?? 'pending'}, status: ${t.status})`
-					)
-					.join('\n');
-
-				backgroundSection = `## Active Background Tasks
-
-This session has ${tasks.length} background task(s) running in separate sessions:
-${taskList}
-
-**CRITICAL:** Task IDs and session IDs persist across compaction - these tasks are still running.
-Use \`agentuity_background_output({ task_id: "..." })\` to check their status.`;
-			}
-
-			// 5. Combine everything into the full prompt
+			// 4. Combine everything into the full prompt
 			const sections: string[] = [];
 			if (instructions) sections.push(instructions);
 			sections.push(sessionStateSection);
-			if (backgroundSection) sections.push(backgroundSection);
 			if (planningState) sections.push(planningState);
 			if (imageDescs) sections.push(imageDescs);
 			if (toolSummaries) sections.push(toolSummaries);
 
-			// 6. Add diagnostics
+			// 5. Add diagnostics
 			const stats: CompactionStats = {
 				planningPhasesCount: countListItems(planningState),
-				backgroundTasksCount: tasks.length,
 				imageDescriptionsCount: countListItems(imageDescs),
 				toolCallSummariesCount: countListItems(toolSummaries),
 				estimatedTokens: Math.ceil(sections.join('\n\n').length / 4),
@@ -229,7 +204,7 @@ Use \`agentuity_background_output({ task_id: "..." })\` to check their status.`;
 			const diagnostics = formatCompactionDiagnostics(stats);
 			if (diagnostics) sections.push(diagnostics);
 
-			// 7. Enforce token budget
+			// 6. Enforce token budget
 			let fullPrompt = sections.join('\n\n');
 			const estimatedTokens = Math.ceil(fullPrompt.length / 4);
 			if (maxTokens > 0 && estimatedTokens > maxTokens) {
@@ -245,24 +220,19 @@ Use \`agentuity_background_output({ task_id: "..." })\` to check their status.`;
 				fullPrompt = trimmed.join('\n\n');
 			}
 
-			// 8. Set the full prompt or push to context
+			// 7. Set the full prompt or push to context
 			if (useCustomPrompt) {
 				output.prompt = fullPrompt;
 			} else {
 				output.context.push(fullPrompt);
 			}
 
-			// 9. Store pre-compaction snapshot to KV (fire-and-forget)
+			// 8. Store pre-compaction snapshot to KV (fire-and-forget)
 			if (useSnapshotToKV) {
 				storePreCompactionSnapshot(sessionId, {
 					timestamp: new Date().toISOString(),
 					sessionId,
 					planningState: planningState ? { raw: planningState } : undefined,
-					backgroundTasks: tasks.map((t) => ({
-						id: t.id,
-						description: t.description || 'No description',
-						status: t.status,
-					})),
 					branch,
 				}).catch(() => {}); // Fire and forget
 			}