@integrity-labs/agt-cli 0.27.168 → 0.27.169

package/dist/bin/agt.js

@@ -33,7 +33,7 @@ import {
   success,
   table,
   warn
-} from "../chunk-ZQGQVROS.js";
+} from "../chunk-4DWE64OJ.js";
 import {
   CHANNEL_REGISTRY,
   DEPLOYMENT_TEMPLATES,
@@ -60,7 +60,7 @@ import {
   renderTemplate,
   resolveChannels,
   serializeManifestForSlackCli
-} from "../chunk-3A2H4ZLD.js";
+} from "../chunk-L2UTBXZS.js";
 
 // src/bin/agt.ts
 import { join as join21 } from "path";
@@ -5019,7 +5019,7 @@ import { execFileSync, execSync } from "child_process";
 import { existsSync as existsSync10, realpathSync as realpathSync2 } from "fs";
 import chalk18 from "chalk";
 import ora16 from "ora";
-var cliVersion = true ? "0.27.168" : "dev";
+var cliVersion = true ? "0.27.169" : "dev";
 async function fetchLatestVersion() {
   const host2 = getHost();
   if (!host2) return null;
@@ -5942,7 +5942,7 @@ function handleError(err) {
 }
 
 // src/bin/agt.ts
-var cliVersion2 = true ? "0.27.168" : "dev";
+var cliVersion2 = true ? "0.27.169" : "dev";
 var program = new Command();
 program.name("agt").description("Augmented CLI \u2014 agent provisioning and management").version(cliVersion2).option("--json", "Emit machine-readable JSON output (suppress spinners and colors)").option("--skip-update-check", "Skip the automatic update check on startup");
 program.hook("preAction", async (thisCommand, actionCommand) => {

package/dist/{chunk-ZQGQVROS.js → chunk-4DWE64OJ.js}

@@ -14,7 +14,7 @@ import {
   registerFramework,
   resolveAvatarEnvUrl,
   wrapScheduledTaskPrompt
-} from "./chunk-3A2H4ZLD.js";
+} from "./chunk-L2UTBXZS.js";
 
 // ../../packages/core/dist/integrations/registry.js
 var INTEGRATION_REGISTRY = [
@@ -3390,32 +3390,43 @@ acknowledge before you start.
 - **FAST (< 60s):** handle inline. Reply via the channel tool
   (slack.reply / telegram.reply / directchat.reply) and end your turn.
 
-- **SLOW (\u2265 60s):** acknowledge first, then handle inline.
+- **SLOW (\u2265 60s):** acknowledge, dispatch to background, stay responsive.
   1. Send a one-line acknowledgement via the channel tool \u2014 short, warm,
      and tell the user you'll come back. Example shape (don't copy verbatim,
      match your voice): "On it \u2014 this'll take a minute or two, I'll ping
      when it's done."
-  2. Do the work yourself in this same session. Use whatever tools you
-     need (MCP, skills, file reads, etc.) \u2014 your parent session has the
-     full MCP surface bound.
-  3. Reply with the result via the channel tool (\`slack.reply\` /
-     \`telegram.reply\` / \`directchat.reply\`), addressing the same thread
-     / chat / conversation you acknowledged in step 1.
-
-> **Why inline and not sub-agent dispatch right now:** there is an
-> upstream Claude Code bug
-> ([anthropics/claude-code#64909](https://github.com/anthropics/claude-code/issues/64909))
-> where sub-agents dispatched via the Task tool with an explicit
-> \`tools:\` allowlist (which is the shape \`channel-message-handler\`
-> uses) get an **empty MCP tool registry** \u2014 every \`mcp__*\` call
-> returns "No such tool available", including the channel reply tools.
-> Dispatching a slow channel reply to \`channel-message-handler\` will
-> therefore silently fail to land: you'd post the one-line ack, the
-> sub-agent would do the analysis fine, but its \`slack.reply\` call
-> would error and the user would never see the substantive reply.
-> Empirically confirmed 2026-06-03 with a 6-tool probe: 0/6 MCP tools
-> bound inside \`channel-message-handler\`. Until Anthropic ships the
-> fix, handling slow channel replies inline is the only working path.
+  2. Dispatch the work to a background sub-agent: the Agent tool with
+     \`subagent_type: general-purpose\` AND \`run_in_background: true\`.
+     Put EVERYTHING the worker needs in the dispatch prompt \u2014 the user's
+     full request, relevant thread context, which integrations/tools to
+     use, and the exact shape of result you want back. The worker inherits
+     your full MCP tool surface but NOT your conversation context.
+  3. End your turn after dispatching. This is the point: you stay free to
+     answer other messages while the worker grinds. Do NOT wait, poll, or
+     dispatch the same work synchronously \u2014 a synchronous dispatch blocks
+     your turn and defeats the purpose.
+  4. When the worker's completion notification arrives (it lands
+     automatically as a system message), read its result and reply via the
+     channel tool (\`slack.reply\` / \`telegram.reply\` / \`directchat.reply\`)
+     to the same thread / chat / conversation you acknowledged in step 1.
+     **You post the substantive reply \u2014 the worker has no channel tools.**
+  5. If the completion notification reports a failure or an unusable
+     result, tell the user what happened and either re-dispatch with a
+     better prompt or handle it inline \u2014 never go silent.
+
+> **Why background dispatch (and why \`general-purpose\`):** validated
+> 2026-06-10 on Claude Code 2.1.170 (ENG-6274 spike,
+> \`docs/spikes/ENG-6274-run-in-background-dispatch.md\`): background
+> dispatch returns immediately, your turn ends, inbound messages get
+> answered in seconds while the worker runs, and the completion arrives
+> as a notification you handle like any other turn. Use
+> \`subagent_type: general-purpose\` (inherit-all tools) \u2014 NOT
+> \`channel-message-handler\` or \`augmented-worker\` \u2014 until ENG-6273
+> re-verifies on this host that the upstream allowlist bug
+> ([anthropics/claude-code#64909](https://github.com/anthropics/claude-code/issues/64909),
+> empirically 0/6 MCP tools in named sub-agents on 2026-06-03) is fixed
+> at the fleet's pinned Claude Code version. \`general-purpose\` escapes
+> that bug by construction either way.
 
 **Why this triage decision still matters more than any other instruction
 below:** if you skip the acknowledgement and just dive into slow work
@@ -3437,25 +3448,29 @@ For background tool work that **isn't** a channel reply \u2014 multi-step data
 pulls, CRM enrichments, research workflows, cross-MCP orchestration \u2014 use
 \`subagent_type: general-purpose\` (Anthropic's built-in). It inherits the
 full MCP tool surface from this session and reliably binds every
-\`mcp__*\` server you have available.
+\`mcp__*\` server you have available. For anything expected to take more
+than a minute, add \`run_in_background: true\` so your turn ends and you
+stay responsive; the completion notification brings you the result.
+Don't background-dispatch trivial work \u2014 each dispatch is a fresh
+context and costs real tokens.
 
 **Why not \`augmented-worker\` for now:** there is an upstream Claude Code
 bug ([anthropics/claude-code#64909](https://github.com/anthropics/claude-code/issues/64909))
 where sub-agents with an explicit \`tools:\` allowlist get an empty MCP
 tool registry \u2014 every \`mcp__*\` call returns "No such tool available."
 \`general-purpose\` uses \`tools: *\` (inherit-all) and escapes the bug.
-Once Anthropic ships the fix, \`augmented-worker\` becomes preferred again
-(restricted tool surface for safety + working MCP binding); the dispatch
-recommendation here will flip back automatically.
+The fix appears to have shipped upstream (verified locally on Claude Code
+2.1.170, 2026-06-10 \u2014 ENG-6269 spike); once ENG-6273 re-verifies it on
+this host's pinned version, \`augmented-worker\` becomes preferred again
+(restricted tool surface for safety + working MCP binding) and
+\`channel-message-handler\` returns as a dispatch target. Until then,
+\`general-purpose\` only.
 
 For slow **channel** replies, see \xA7 FIRST ACTION above \u2014 those are
-currently handled inline (not dispatched) because \`channel-message-handler\`
-shares the explicit-allowlist shape and so suffers the same upstream
-bug. Empirically confirmed 2026-06-03 on agt-aws-1 with a 6-tool probe:
-0/6 MCP tools bound inside \`channel-message-handler\` (matching the
-\`augmented-worker\` result). When Anthropic ships the upstream fix, both
-named sub-agents will work again and the FIRST ACTION triage will switch
-back to dispatch.
+dispatched as background \`general-purpose\` workers and **you** post the
+result back to the channel when the completion notification arrives
+(\`channel-message-handler\` is not yet the dispatch target for the same
+ENG-6273-pending reason).
 
 ${activeTasksSection}${personalitySection}## Identity
 
@@ -8222,4 +8237,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-ZQGQVROS.js.map
+//# sourceMappingURL=chunk-4DWE64OJ.js.map