@integrity-labs/agt-cli 0.28.32 → 0.28.34

package/dist/bin/agt.js

@@ -33,7 +33,7 @@ import {
   success,
   table,
   warn
-} from "../chunk-KJVDXL3L.js";
+} from "../chunk-DLCUI4J5.js";
 import {
   CHANNEL_REGISTRY,
   DEPLOYMENT_TEMPLATES,
@@ -60,7 +60,7 @@ import {
   renderTemplate,
   resolveChannels,
   serializeManifestForSlackCli
-} from "../chunk-VIIPFWE4.js";
+} from "../chunk-R5CP4WAO.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.32" : "dev";
+var cliVersion = true ? "0.28.34" : "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.32" : "dev";
+var cliVersion2 = true ? "0.28.34" : "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-KJVDXL3L.js → chunk-DLCUI4J5.js}

@@ -14,7 +14,7 @@ import {
   registerFramework,
   resolveAvatarEnvUrl,
   wrapScheduledTaskPrompt
-} from "./chunk-VIIPFWE4.js";
+} from "./chunk-R5CP4WAO.js";
 
 // ../../packages/core/dist/integrations/registry.js
 var INTEGRATION_REGISTRY = [
@@ -3390,43 +3390,54 @@ 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 background, stay responsive.
+- **SLOW (\u2265 60s):** acknowledge, dispatch to a background channel worker,
+  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 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.
+  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.
   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
+  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
 > ([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.
+> 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.
 
 **Why this triage decision still matters more than any other instruction
 below:** if you skip the acknowledgement and just dive into slow work
@@ -3446,31 +3457,20 @@ 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: 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.
+\`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.
 
 For slow **channel** replies, see \xA7 FIRST ACTION above \u2014 those are
-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).
+dispatched as background \`channel-message-handler\` workers, the channel-aware
+sibling of \`augmented-worker\`, which post the reply themselves over the
+audited channel path.
 
 ${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, 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).
+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.
 
 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: 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.
+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).
 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-channel__slack_reply\`, \`mcp__telegram-channel__telegram_reply\`, \`mcp__direct-chat__direct_chat_reply\`, etc.) so the call goes through the audited path.
+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.
 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,11 +7266,16 @@ function requireHost() {
 }
 
 // src/lib/api-client.ts
-var agtCliVersion = true ? "0.28.32" : "dev";
+var agtCliVersion = true ? "0.28.34" : "dev";
+var lastConfigHash = null;
+function setConfigHash(hash) {
+  lastConfigHash = hash && hash.length > 0 ? hash : null;
+}
 var cachedExchange = null;
 var exchangeInFlight = null;
 function invalidateExchange() {
   cachedExchange = null;
+  lastConfigHash = null;
 }
 async function exchangeApiKey(rawKey, retried = false, opts = {}) {
   if (!opts.forceRefresh && cachedExchange && Date.now() < cachedExchange.expiresAt - 6e4) {
@@ -7375,6 +7380,9 @@ async function buildHeaders() {
     // actions so bug rates can be tracked per CLI version.
     "X-Agt-Cli-Version": agtCliVersion
   };
+  if (lastConfigHash) {
+    headers["X-Config-Hash"] = lastConfigHash;
+  }
   const team = getActiveTeam() ?? exchange.teamSlug;
   if (team) {
     headers["X-Team-Slug"] = team;
@@ -8289,6 +8297,7 @@ export {
   PROD_AGT_HOST,
   getHost,
   requireHost,
+  setConfigHash,
   exchangeApiKey,
   ApiError,
   api,
@@ -8317,4 +8326,4 @@ export {
   managerInstallSystemUnitCommand,
   managerUninstallSystemUnitCommand
 };
-//# sourceMappingURL=chunk-KJVDXL3L.js.map
+//# sourceMappingURL=chunk-DLCUI4J5.js.map