@integrity-labs/agt-cli 0.28.38 → 0.28.40

package/dist/bin/agt.js

@@ -33,7 +33,7 @@ import {
   success,
   table,
   warn
-} from "../chunk-IJT4B5PH.js";
+} from "../chunk-DA776TZO.js";
 import {
   CHANNEL_REGISTRY,
   DEPLOYMENT_TEMPLATES,
@@ -60,7 +60,7 @@ import {
   renderTemplate,
   resolveChannels,
   serializeManifestForSlackCli
-} from "../chunk-RYB5QSVS.js";
+} from "../chunk-X5E2Q3W2.js";
 
 // src/bin/agt.ts
 import { join as join21 } from "path";
@@ -4773,7 +4773,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.28.38" : "dev";
+var cliVersion = true ? "0.28.40" : "dev";
 async function fetchLatestVersion() {
   const host2 = getHost();
   if (!host2) return null;
@@ -5696,7 +5696,7 @@ function handleError(err) {
 }
 
 // src/bin/agt.ts
-var cliVersion2 = true ? "0.28.38" : "dev";
+var cliVersion2 = true ? "0.28.40" : "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-2V5QUET6.js → chunk-57MHPANB.js}

@@ -1,7 +1,7 @@
 import {
   claudeModelAlias,
   isClaudeFastMode
-} from "./chunk-RYB5QSVS.js";
+} from "./chunk-X5E2Q3W2.js";
 import {
   reapOrphanChannelMcps
 } from "./chunk-XWVM4KPK.js";
@@ -1487,4 +1487,4 @@ export {
   stopAllSessionsAndWait,
   getProjectDir
 };
-//# sourceMappingURL=chunk-2V5QUET6.js.map
+//# sourceMappingURL=chunk-57MHPANB.js.map

package/dist/{chunk-IJT4B5PH.js → chunk-DA776TZO.js}

@@ -14,7 +14,7 @@ import {
   registerFramework,
   resolveAvatarEnvUrl,
   wrapScheduledTaskPrompt
-} from "./chunk-RYB5QSVS.js";
+} from "./chunk-X5E2Q3W2.js";
 
 // ../../packages/core/dist/integrations/registry.js
 var INTEGRATION_REGISTRY = [
@@ -3390,54 +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, dispatch to a background channel worker,
-  stay responsive.
+- **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. Dispatch the work to a background \`channel-message-handler\` sub-agent:
-     the Agent tool with \`subagent_type: channel-message-handler\` 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 \u2014 plus the **channel-specific routing
-     keys** its reply tool needs: Slack threads \u2192 \`{ channel_id, thread_ts }\`;
-     Slack non-thread DMs \u2192 \`{ channel_id }\`; Telegram \u2192 \`{ chat_id, message_id }\`;
-     Direct Chat \u2192 \`{ conversation_id }\`. Pass these verbatim from the
-     inbound \`<channel>\` tag \u2014 don't substitute a generic \`message_ts\`,
-     since only Slack threads use it. The worker inherits your full MCP tool
-     surface but NOT your conversation context.
+  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. \`channel-message-handler\` posts the substantive reply **itself**, via
-     its own channel reply tool (\`slack.reply\` / \`telegram.reply\` /
-     \`directchat.reply\`) addressed by the routing keys you passed \u2014 you do
-     NOT relay it. Its completion notification lands automatically as a
-     system message; read it just to confirm the reply went out.
-  5. If the completion notification reports a failure \u2014 or that the worker
-     could not post \u2014 post the reply (or a brief status) yourself to the
-     same thread / chat / conversation you acknowledged in step 1, and
-     either re-dispatch with a better prompt or handle it inline. Never go
-     silent.
-
-> **Why a background \`channel-message-handler\` dispatch:** two findings
-> combine into this shape. (1) ENG-6274 (2026-06-10, Claude Code 2.1.170,
-> \`docs/spikes/ENG-6274-run-in-background-dispatch.md\`): a background
-> dispatch returns immediately, your turn ends, and inbound messages get
-> answered in seconds while the worker runs \u2014 the completion arrives as a
-> notification you handle like any other turn. (2) ENG-6273 (on-host probe
-> at the fleet's pinned 2.1.170,
-> \`docs/spikes/ENG-6273-verify-64909-onhost-probe.md\`): the upstream
-> empty-registry bug
+  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),
-> 0/6 MCP tools in named sub-agents on 2026-06-03) is **fixed** \u2014 a named
-> sub-agent with an explicit \`tools:\` allowlist binds the full MCP surface
-> again (10/11, zero empty-registry misses). So \`channel-message-handler\`
-> can reach its own channel reply tool: dispatch it in the background and it
-> both does the work AND posts the reply over the audited channel path,
-> while you stay free.
+> 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
@@ -3457,20 +3446,31 @@ consistency.
 
 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: augmented-worker\`. It carries an explicit allowlist of
-every \`mcp__*\` server you have wired \u2014 a tighter, safer tool surface than
-inherit-all \u2014 and binds them reliably now that ENG-6273's on-host probe
-confirmed the upstream allowlist bug (claude-code#64909) is fixed at the
-fleet's pinned Claude Code 2.1.170. 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.
+\`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. 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.
+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
-dispatched as background \`channel-message-handler\` workers, the channel-aware
-sibling of \`augmented-worker\`, which post the reply themselves over the
-audited channel path.
+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
 
@@ -3500,10 +3500,10 @@ ${resolvedChannels?.includes("slack") ? `
 
 You have a Slack MCP server connected. **First, see \xA7 FIRST ACTION on
 every channel message: triage** at the top of this document \u2014 decide
-fast vs slow before anything else. Handle fast requests inline;
-acknowledge slow ones, then dispatch them to a background
-\`channel-message-handler\` worker (which posts the reply itself) and stay
-responsive \u2014 see the FIRST ACTION section for the full rationale.
+fast vs slow before anything else, then acknowledge inline before
+diving into slow work (sub-agent dispatch for channel replies is
+currently disabled due to an upstream Claude Code bug; see the FIRST
+ACTION section for the full rationale).
 
 For fast requests, respond directly in the conversation. You can also
 proactively use:
@@ -5330,7 +5330,7 @@ If a capability seems missing, **check first** \u2014 run the CLI, list tools (\
 `;
   return `---
 name: augmented-worker
-description: General-purpose background worker for multi-step tool tasks the parent doesn't want to inline (data pulls, multi-API workflows, CRM enrichments, research that needs MCP tools). Has explicit access to every \`mcp__*\` server the parent has wired. Use this \u2014 not \`general-purpose\` and not the read-only researcher/reviewer subagents from other plugins \u2014 whenever the work requires calling MCP tools (e.g. \`mcp__granola__*\`, \`mcp__composio_attio__*\`, \`mcp__slack__*\`, \`mcp__augmented__*\`). Many community subagents declare restrictive \`tools:\` allowlists that exclude MCP tools, so dispatching to them will silently produce "No such tool available." failures and force unsafe fallback paths (reading raw secrets from \`.mcp.json\`, bypassing the Credential Access Control guardrail).
+description: Background worker for multi-step tool tasks the parent doesn't want to inline (data pulls, multi-API workflows, CRM enrichments, research that needs MCP tools). Carries an explicit \`mcp__*\` wildcard allowlist for every server the parent has wired. **Until [anthropics/claude-code#64909](https://github.com/anthropics/claude-code/issues/64909) ships an upstream fix, prefer \`subagent_type: general-purpose\` for MCP-tool dispatch** \u2014 the bug is in Claude Code's sub-agent dispatch path: sub-agents with an explicit \`tools:\` allowlist get an empty MCP tool registry (every \`mcp__*\` call returns "No such tool available."), while \`general-purpose\` (\`tools: *\` inherit-all) correctly binds the full MCP surface. This subagent's allowlist is correct and will work the moment Anthropic lands the fix; until then it is retained for the eventual structural fix and the rare case where you specifically need a restricted tool surface AND can accept the MCP gap. See [[ENG-5938]] for the workaround tracker.
 background: true
 tools: ${tools}
 ---
@@ -5344,7 +5344,7 @@ Your \`tools:\` allowlist (above) names every MCP server the parent has connecte
 ## Hard rules \u2014 Credential Access Control
 
 1. **Never** read raw secrets out of \`.mcp.json\`, \`~/.augmented/*/provision/.mcp.json\`, \`.env.integrations\`, or any agent config file. Those files contain bot tokens, API keys, and OAuth credentials. The Credential Access Control guardrail (\`block_read: true\` on secrets) treats reads of those values as a violation regardless of intent. As **defence-in-depth (not structural enforcement)**, the plugin's \`settings.json\` also denies \`Bash(cat:*/.mcp.json)\`, \`Bash(cat:*/.env.integrations)\`, and \`Bash(jq:*/.mcp.json)\` (ENG-5901 / ADR-0018) \u2014 these block the obvious copy-paste paths but a determined in-process reader can still reach the values; the durable fix is Phase 2/3 of ADR-0018.
-2. **Never** post Slack messages via raw \`chat.postMessage\` + a bot token lifted from config. Use the channel MCP's reply tool (\`mcp__slack__slack_reply\`, \`mcp__telegram__telegram_reply\`, \`mcp__direct-chat__direct_chat_reply\`, etc.) so the call goes through the audited path.
+2. **Never** post channel messages via raw API calls + bot tokens lifted from config. Use the channel MCP reply tools (\`mcp__slack__slack_reply\`, \`mcp__telegram__telegram_reply\`, \`mcp__direct_chat__direct_chat_reply\`, etc.) so calls go through the audited path.
 3. If an \`mcp__*\` tool you expect to be available returns "No such tool available.", **stop and surface the gap to the parent** in your summary rather than working around it. A missing MCP binding is a platform bug worth fixing \u2014 it's the exact failure shape this sub-agent was added to prevent (see ENG-5897 / ENG-5905).
 4. When verifying a capability is wired, confirm the relevant env var exists **without printing its value** \u2014 use \`[ -n "$POSTIZ_API_KEY" ] && echo present || echo absent\`, never \`echo $POSTIZ_API_KEY\`. The Credential Access Control guardrail covers tool-call output as well as file reads.
 
@@ -7266,7 +7266,7 @@ function requireHost() {
 }
 
 // src/lib/api-client.ts
-var agtCliVersion = true ? "0.28.38" : "dev";
+var agtCliVersion = true ? "0.28.40" : "dev";
 var lastConfigHash = null;
 function setConfigHash(hash) {
   lastConfigHash = hash && hash.length > 0 ? hash : null;
@@ -8326,4 +8326,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-IJT4B5PH.js.map
+//# sourceMappingURL=chunk-DA776TZO.js.map