Best possible solution:

Keep one canonical fix that carries the unavailable reason into every visible approval renderer, including Telegram native and forwarding payloads, then require a passing Telegram Desktop proof on the final head.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection and Mantis evidence show the current PR head still omits the new reason from Telegram approval payload construction, so the Telegram prompt reproduces the old policy wording for redirected non-persistable commands.

Is this the best way to solve the issue?

No. A typed unavailable reason is the right fix shape, but this implementation is incomplete until the reason is passed through Telegram native and forwarding payload builders and verified with real Telegram proof.

Full review comments:

• [P2] Pass the reason into Telegram approval payloads — extensions/telegram/src/approval-handler.runtime.ts:75-92
  The PR adds allowAlwaysUnavailableReason to the shared approval view and reply helper, but this Telegram native builder still calls buildExecApprovalPendingReplyPayload without passing that field, so the helper falls back to the policy wording. The Telegram forwarding builder has the same omission, and the Mantis run at this head confirms the visible prompt still shows the old text.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.93

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against c52adf7505a7.

Label justifications:

• P2: This is a bounded approval prompt correctness bug with limited blast radius, but the PR currently fails a user-visible Telegram proof path.
• merge-risk: 🚨 other: Merging this PR as-is would ship a visible approval-copy fix that is known not to reach Telegram native approval prompts at the current head.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The linked Mantis Telegram Desktop proof for the current head reports candidate failure; after repairing the payload path, contributors or maintainers should add redacted passing proof and update the PR body to trigger re-review.
• mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. This PR changes visible Telegram approval prompt copy, so a short Telegram Desktop proof should demonstrate the final behavior.

PR surface:

Source +228, Tests +127. Total +355 across 65 files.

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs extensions/telegram/src/approval-handler.runtime.test.ts extensions/telegram/src/exec-approval-forwarding.test.ts src/infra/exec-approval-reply.test.ts src/infra/approval-view-model.test.ts.
• [P1] pnpm ui:i18n:check.
• [P1] Mantis Telegram Desktop proof for redirected command approval at the final head.

What I checked:

• Repository policy applied: Root AGENTS.md and relevant scoped guides were read; Telegram maintainer notes require real Telegram proof for transport-visible approval behavior, and the plugin SDK guide treats approval renderer surface changes as public-contract sensitive. (AGENTS.md:1, c52adf7505a7)
• Current main still collapses reasons: Current main removes allow-always for both ask === "always" and one-shot persistence, so allowed decisions alone cannot distinguish policy from non-persistable command shape. (src/infra/exec-approvals.ts:1824, c52adf7505a7)
• PR head adds the reason to the view: At the PR head, the approval view model copies request.request.allowAlwaysUnavailableReason into the exec approval view, making the reason available to native approval renderers if they pass it on. (src/infra/approval-view-model.ts:75, 4588eb88a160)
• Telegram native path still drops the reason: At the PR head, buildPendingPayload calls buildExecApprovalPendingReplyPayload with command, host, node, allowed decisions, and expiry, but without allowAlwaysUnavailableReason; the shared helper therefore falls back to the policy wording for native Telegram prompts. (extensions/telegram/src/approval-handler.runtime.ts:75, 4588eb88a160)
• Telegram forwarding path still drops the reason: At the PR head, buildTelegramExecApprovalPendingPayload also calls buildExecApprovalPendingReplyPayload without the new reason, so forwarded Telegram approval prompts have the same gap. (extensions/telegram/src/exec-approval-forwarding.ts:34, 4588eb88a160)
• Real proof failed at the current PR head: Live PR comments include Mantis Telegram Desktop proof for candidate 4588eb88a160ad8c0f1dd1ed817c6f3c16d3d6fa reporting that the candidate still shows the same old Allow Always unavailable wording. (4588eb88a160)

Likely related people:

• jesse-merhi: The non-persistable command behavior and authorization planner changes trace to c9707ab635b9, which touched src/infra/exec-approvals.ts and both exec host paths. (role: one-shot persistence feature-history owner; confidence: high; commits: c9707ab635b9, 42f0822bfac9; files: src/infra/exec-approvals.ts, src/agents/bash-tools.exec-host-gateway.ts, src/agents/bash-tools.exec-host-node.ts)
• gumadeiras: The generic Allow Always unavailable policy copy and related effective-policy approval reporting path trace to ba735d015809. (role: introduced effective-policy approval reporting path; confidence: high; commits: ba735d015809; files: src/infra/exec-approval-reply.ts, src/infra/exec-approval-forwarder.ts, src/infra/exec-approvals-effective.ts)
• Bartok: Current checkout blame for the relevant approval helper and Telegram approval builder lines points at 4d9cd7d22755, a broad recent agents truncation change in the shallow history. (role: recent current-main line provenance; confidence: low; commits: 4d9cd7d22755; files: src/infra/exec-approvals.ts, src/infra/exec-approval-reply.ts, extensions/telegram/src/approval-handler.runtime.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.