Best possible solution:

Thread the typed unavailable reason through all production approval prompt data paths, keep Control UI copy in the i18n catalog, prove redirected-command and ask=always behavior in a real prompt, then choose one canonical PR for the linked bug.

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

Yes, from source with high confidence. Current main removes Allow Always for both ask=always and one-shot persistence while user-facing prompt builders still print policy-only copy when the decision is absent; I did not run a live gateway flow in this read-only review.

Is this the best way to solve the issue?

No. The typed reason approach is plausible, but this branch stops short of the foreground/embedded/Telegram production call sites and bypasses Control UI i18n, so it is not yet the narrow complete fix.

Full review comments:

• [P1] Thread the reason into production prompt callers — src/infra/exec-approval-reply.ts:382-385
  The new reply formatter can only show reason-specific text when callers pass allowAlwaysUnavailableReason, but the foreground tool result and Telegram native/forwarding paths still pass neither that field nor an equivalent fact. That means the reported main-agent/subagent and Telegram approval prompts can keep stale policy-only or generic copy for redirected one-shot commands, so please carry the typed reason through ExecToolDetails, embedded/Telegram callers, and production-shaped tests.
  Confidence: 0.92
• [P2] Keep Control UI warning text in i18n — ui/src/ui/views/exec-approval.ts:159-166
  This replaces the localized t("execApproval.allowAlwaysUnavailable") warning with English strings from a core formatter. Non-English Control UI locales cannot translate the new reason-specific warnings, so add UI i18n keys and generated locale metadata instead of rendering hardcoded core copy here.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.91

AGENTS.md: found and applied where relevant.

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

Label justifications:

• P2: This is a bounded approval prompt regression that misleads users and adds repeated approval friction without blocking all exec usage.
• merge-risk: 🚨 other: Merging this incomplete prompt-copy fix could leave different approval surfaces showing conflicting or stale explanations for the same one-shot command.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists focused tests only; it does not include after-fix terminal, log, screenshot, recording, or live prompt proof for the redirected-command behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The linked bug and approval prompt copy are Telegram-visible, and a short Telegram Desktop recording can directly show whether the final native prompt text is correct.

PR surface:

Source +137, Tests +162. Total +299 across 21 files.

What I checked:

• Repository policy read: Root AGENTS.md plus scoped agent, gateway, server-methods, plugin SDK, UI, and Telegram maintainer notes were read; the review applied the whole-surface approval and i18n guidance. (AGENTS.md:1, d1b917120a47)
• Linked bug scope: The linked open bug reports the misleading Allow Always text from main agent, subagent, and Telegram approval prompts for redirected commands under ask=on-miss.
• Current-main cause collapse: Current main removes allow-always for both ask=always and one-shot persistence, so downstream renderers need a separate reason to distinguish policy from non-persistable command state. (src/infra/exec-approvals.ts:1819, d1b917120a47)
• Foreground tool-result prompt still policy-only: The current foreground approval-pending message still prints the policy explanation whenever allow-always is absent; this PR does not modify this file or thread the new reason into this call path. (src/agents/bash-tools.exec-runtime.ts:403, d1b917120a47)
• ExecToolDetails lacks reason plumbing: The approval-pending tool details carry allowed decisions but no ask or allow-always unavailable reason, so embedded/subagent renderers cannot recover the new typed reason from production details. (src/agents/bash-tools.exec-types.ts:133, d1b917120a47)
• Telegram native prompt caller lacks reason: The Telegram native approval handler calls buildExecApprovalPendingReplyPayload without ask or allowAlwaysUnavailableReason, so the PR's new reply helper cannot show the specific one-shot reason there. (extensions/telegram/src/approval-handler.runtime.ts:75, d1b917120a47)

Likely related people:

• jesse-merhi: Authored the Tree-sitter command authorization planner work that introduced one-shot persistence and unavailable-decision handling for Allow Always. (role: 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: Authored the effective exec approval reporting/actions PR that added generic unavailable Allow Always copy across shared approval surfaces. (role: introduced effective-policy reporting path; confidence: high; commits: ba735d015809; files: src/infra/exec-approval-reply.ts, src/infra/exec-approval-forwarder.ts, src/agents/bash-tools.exec-runtime.ts)
• ooiuuii: Recent merged history touches the Control UI i18n formatter pipeline, which is relevant to the PR's hardcoded Control UI warning copy. (role: adjacent UI i18n contributor; confidence: medium; commits: 9d800b71c060; files: scripts/control-ui-i18n.ts, ui/src/i18n/locales/en.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.