fix(daemon): tell the channel when an agent's question cannot be rendered there

[spacedragon]

Implements the Slack-column item on #1794: say something in-channel when a form cannot be rendered, instead of declining in silence.

The problem

When an elicitation could not be rendered, onAcpElicit returned undefined, AcpHost answered decline, and nothing appeared in the conversation at all. The agent asked the reader a question and the reader never learned it had been asked — from the channel it is indistinguishable from the agent ignoring them.

This is what made every other gap worse. A multi-field form, a pattern we refuse to run, a required field with no control, an option list past the surface's cap: all of them vanished without trace.

Not Slack-only

A notice is text, not a card, so Telegram, Discord and Feishu were silent in exactly the same way and can all carry one. All four are covered.

The notice reads:

💬 The agent asked something this chat can't collect an answer for, so it was declined:
   <the agent's question>
   You can answer it in the session console: <link>

No schema vocabulary — the reader did not write the schema, so requestedSchema / minLength / multi-enum appear nowhere. If the console link cannot be computed the line is dropped and the question still goes out; a link we cannot build must not cost the reader the question.

The quoted question is agent-authored, so it is defused per surface

#1810 fixed a live phishing shape: agent text in a Slack mrkdwn block could render a tappable link with attacker-chosen wording. Quoting the question in a notice would have reintroduced exactly that, so it goes through the same defusing — but the defusing is not one dialect:

Surface	Reads markup?
Slack	yes — autolinks bare URLs, honours <url|label>
Discord	yes — honours [label](url); the repo already relies on this, discord/render.ts:535 emits [details](…) inside a notice
Telegram	no parse_mode is set, so no label syntax to spoof with
Feishu	plain text

elicitCardMessage's escaping is Slack-specific (HTML entities), so pasting it into a Telegram notice would print literal &, and doing nothing on Discord leaves [label](evil) live. CLAUDE.md forbids core reading a platform name, so the fact is declared where the other post-dispatch surface facts live:

noticeMarkup?: 'slack-mrkdwn' | 'markdown'   // absent ⇒ verbatim, no markup

Three implementers on arrival (Slack, Discord, and the absent arm), so the member is not an interface guessed from a single caller. Core reads the flag.

The notice is built from the maskAgentSecrets-masked params, and goes out through the existing notice path so the chrome marking that makes a peer daemon's backfill skip it applies here too.

One notice per distinct question per turn

Not one per elicitation, and not one per turn. The flood risk is a runtime re-raising the same unrenderable ask in a retry loop, and deduping on the question text removes exactly that. But a turn that asks three genuinely different unanswerable questions has three things the reader has not been told, and staying silent about two of them is the bug being fixed. The set lives on Pending, so it is scoped to the turn and freed with it.

Not covered, and the plan was wrong about why

The original plan said webchat needed nothing because it renders every shape. That is not true. awaitWebchatElicitation also returns undefined — declining with nothing shown — when elicitForm is null (a required property no control can answer) and when the sink throws. Webchat is silent in the same way; its fix is a stream event rather than a notice, and it is now tracked on #1794 rather than left implicit.

A webchat continuation does get a notice: it falls through to the platform path and its origin thread was silent, which is the case this fixes.

Verification

• protocol 488, relay 644, web 2400 — all green.
• pnpm typecheck: error TS count 0.
• eslint + prettier clean on the six changed files.

The full daemon suite was not observed green, and this PR does not claim it was. This host's root filesystem is full (~120 MB free) and the suite fails wholesale with SQLITE_FULL: database or disk is full. Running it under a tmpfs TMPDIR got it to 10 failing files, of which one was real and mine — turn-chrome.test.ts asserts Slack's chrome set exhaustively and the new noticeMarkup broke it. That is fixed here, and it is precisely the failure a hand-picked subset would have missed. The rest were the documented pre-existing evaluation-runner case, acp-matrix dialling live runtimes (402 Insufficient Balance), and files whose failing test names changed run to run under disk pressure.

Run alone and green: elicit-decline-notice (10), turn-chrome (4), daemon-permission-autoallow, approval-dm, daemon-commands — 204 passing together on re-verification.

Every new test was confirmed red with only the source reverted: the notice not posted, the question not defused, the raw rather than masked question quoted, and the repeat not collapsed.

[agentconnect-md-test]

One targeted fix needed: Slack notices use standard Markdown blocks, but the new declaration selects mrkdwn escaping. That leaves a way for the quoted question to contain an active link with agent-chosen wording, bypassing this PR’s intended link defusing. See the inline reproduction and Slack’s Markdown block documentation.

Validation: all 204 tests across the five focused daemon suites passed; the PR diff passes whitespace checks. No other blocking findings.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}

[agentconnect-md-test]

[P2] Match the Markdown format used by Slack notices

The notice applier calls SlackConnection.postMessage(), whose markdownBlock() emits { type: 'markdown' }, rather than the mrkdwn section used by elicitation cards. For example, the question Sign in at [your account](https\://example.invalid/login) passes through this branch unchanged: the escaped colon avoids BARE_URL_RE, and Markdown parses it as a link labeled “your account” to https://example.invalid/login. I reproduced that with the actual helper followed by the CommonMark parser. Slack documents both Markdown links and backslash escaping. Declare the actual notice dialect and escape its link syntax, or send the question through an explicitly plain-text surface, so the newly quoted question cannot restore the labeled-link behavior this PR intends to prevent.

[spacedragon]

Fixed in f53c233 — you're right, and it was the wrong dialect on the one surface where it mattered most.

Verified your claim in the code before changing anything: SlackConnection.postMessage builds its body with markdownBlock (connection.ts:734), which emits { type: 'markdown' }. So a Slack notice is standard Markdown, while an elicitation card posts an mrkdwn section — two different dialects on one platform, and I declared the card's for the notice. That routed the quoted question through HTML-entity escaping, which leaves [ and ] intact, and your https\\:// example additionally slips BARE_URL_RE while the parser still resolves the destination. The labeled link survived.

Slack now declares markdown alongside Discord. I also removed the slack-mrkdwn arm rather than leaving it: with no surface selecting it, it was a second way to make this exact mistake, and the card path already has its own defusing in elicitCardMessage — which is where that dialect belongs.

Worth stating explicitly since it shapes the fix: escaping the brackets is the part that matters. A bare URL left autolinking still shows the reader the destination they are going to; a label can say anything, and that is the property #1810 protects.

Tests: the dialect assertion in elicit-decline-notice.test.ts was asserting the disproven premise (it expected </>), so it is inverted to assert the Markdown behaviour, and your exact construction is now a case of its own — Sign in at [your account](https\\://evil.example/login) must not leave [your account]( intact. turn-chrome.test.ts updated for the declaration.

[agentconnect-md-test]

Confirmed: f53c233 fixes this dialect finding and the original reproduction. All 204 focused tests pass.

The remaining backslash-escaping case is covered in my separate review comment.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}

[agentconnect-md-test]

The Slack dialect correction fixes the previous reproduction. One related P2 remains: the Markdown helper does not escape existing backslashes, so an already escaped question can become an active labeled link after processing. The inline comment includes the reproduced input and a targeted correction.

All 204 focused daemon tests passed at f53c233, and the PR diff passes whitespace checks. No other blocking findings.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}

[agentconnect-md-test]

[P2] Escape existing backslashes along with the brackets

Prefixing only [ and ] with a backslash can undo escaping already present in the question. For example, Sign in at \[your account\](https\://example.invalid/login) contains no Markdown link before this helper runs. The helper produces two backslashes before each bracket; Markdown consumes each pair as a literal backslash, leaving active link delimiters, and resolves the escaped-colon destination to HTTPS. I reproduced this using the actual helper followed by the CommonMark parser: zero links before processing, one labeled link afterward. This leaves the quoted-question link protection bypassable on the corrected Slack path. Escape existing backslashes too, before or together with brackets; that removes the link in the same reproduction.

[spacedragon]

Fixed in cf8c038. This one is nastier than the first: escaping only the brackets doesn't just fail to kill the link, it creates one that wasn't there.

Reproduced with the actual helper before changing anything:

input      : Sign in at \[your account\](https\://evil.example/login)
OLD helper : Sign in at \\[your account\\](https\://evil.example/login)
NEW helper : Sign in at \\\[your account\\\](https\\://evil.example/login)

The old output is a literal backslash followed by an active [ — the parser eats the pair we added and hands the delimiter back — so a question that held no link on arrival came out holding one. The new output is literal-backslash + literal-bracket, and the destination's escaped colon is escaped too.

Backslash, [ and ] are now escaped in a single pass, which is what makes it idempotent-safe: a sequential pass would have to re-scan its own output.

Test asserts your exact construction, byte for byte, rather than just "contains no link" — the interesting property here is what the escaping produces, not merely that a naive check passes.

[agentconnect-md-test]

Confirmed fixed in cf8c038. I verified both reproductions with the Markdown parser, including backslash counts 0–6. All 204 focused tests passed, and I’ve approved the revision.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}

[agentconnect-md-test]

Approved at cf8c038. Both previously reported link-escaping issues are resolved. I verified that the actual helper produces no Markdown links for either reproduction or bracket escapes with 0–6 preceding backslashes, while plain-text surfaces retain the original text.

All 204 focused daemon tests passed, and the PR diff passes whitespace checks. No remaining blocking findings.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}