fix(slack): clamp approval message so chat_update survives HTML-escaped >3000-char sections

[Peterskaronis]

Problem

Interactive command-approval buttons (Allow Once / Allow Session / Always Allow / Deny) appear dead: clicking leaves the message visually unchanged. The approval does resolve — the agent unblocks and continues — but the message never redraws to strip the buttons and stamp the decision, so from the user's seat "nothing happens" and they re-click.

Root cause

send_exec_approval budgets the command preview against Slack's 3000-char section limit measured on the raw string. But Slack HTML-escapes < > & when it stores the message (> -> >, +3 chars each). Dangerous commands — the ones full of redirects / pipes / && that trigger approval in the first place — grow once escaped.

chat.postMessage accepts the escaped text, but the chat.update fired on button click (_handle_approval_action) enforces the 3000 cap strictly and fails:

invalid_blocks: must be less than 3001 characters [json-pointer:/blocks/0/text/text]

so the redraw silently fails (only a logger.warning), leaving the buttons on screen.

Observed live: a prompt budgeted to exactly 3000 raw chars was stored by Slack at 3061 (escaping added 61 chars: >x7, <x8, &x4). Every approval update failed while the approval itself resolved normally.

Fix

• _handle_approval_action — clamp the echoed section text to 2900 chars before chat_update. The buttons are being stripped anyway, so truncating the echoed command is harmless, and it guarantees the decision update never fails regardless of escaping.
• send_exec_approval — target 2900 instead of 3000 so the stored (escaped) section stays under the cap, avoiding the rarer case where a metacharacter-heavy command escapes past 3000 on the initial post and loses its buttons entirely.

Cosmetic / update-path only; no change to approval semantics.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #53701 — both fix the same #53693 bug (Slack chat.update fails with invalid_blocks when HTML-escaping inflates the approval section past 3000 chars, leaving the buttons on screen) via the same mechanism: truncate the echoed section text in _handle_approval_action before chat.update, in plugins/platforms/slack/adapter.py. #53701 (2026-06-27) is the earliest-open PR for this fix and is canonical; this PR (2026-07-09) additionally tightens send_exec_approval to a 2900 budget, but the core change is the same code-site + mechanism. Both are the post-decision counterpart to the merged send-time fix #43444.

[teknium1]

Thanks for targeting the real post-decision chat.update failure.

Problems

• The same unbounded reconstruction remains in _handle_slash_confirm_action at plugins/platforms/slack/adapter.py:3511-3539; it sends original_text unchanged at :3522, so slash-confirm cards retain this failure mode.
• This PR adds no regression coverage. Existing approval and slash-confirm tests in tests/gateway/test_slack_approval_buttons.py:174-348 do not provide an inflated interaction payload or assert the section length sent to chat_update.

Suggested changes

• Apply the bounded-section logic to both update handlers, ideally through a shared helper.
• Add one regression test per handler for an over-limit echoed section and assert the outgoing update block is capped.

The earlier canonical PR #53701 already demonstrates both sibling coverage and tests. This is an automated hermes-sweeper review.

[teknium1]

Please apply the same cap to _handle_slash_confirm_action: current main still rebuilds its chat_update section from unbounded original_text at plugins/platforms/slack/adapter.py:3511-3523, so slash-confirm cards retain the same failure mode.

[teknium1]

Closing as superseded by #69317 (merged): the escape-inflation clamp landed via #53701 (earlier) plus the new sanitize_blocks() boundary; the 2900-char send budget became unnecessary once the update boundary clamps.

Thanks for digging into this — the consolidated fix stands on the cluster's collective analysis, and your work is credited in #69317's summary.