Best possible solution:

Use #97077 as the canonical landing candidate after maintainer review, then close or supersede the narrower overlapping branches.

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

Yes. Current main source removes Allow Always for both ask=always and one-shot persistence, while the reported and Mantis baseline prompts show policy-only copy whenever Allow Always is absent.

Is this the best way to solve the issue?

No. This is a useful partial fix, but the best landing path is the broader proof-positive sibling branch that carries the needed context through production prompt surfaces and preserves the missing-ask fallback.

Security review:

Security review cleared: The diff changes approval prompt text and tests only; no dependency, workflow, secret, permission, package, or supply-chain surface changed.

AGENTS.md: found and applied where relevant.

What I checked:

• Repository policy read: Root review policy was read fully and applied; no narrower AGENTS.md owns src/infra, and the Telegram maintainer note applied because this PR affects Telegram-visible approval prompts. (AGENTS.md:1, 7bbd09047bd7)
• Current main collapses policy and one-shot causes: resolveExecApprovalAllowedDecisions removes allow-always for both ask === "always" and one-shot persistence, so renderers need more context than the allowed decision list to explain the cause correctly. (src/infra/exec-approvals.ts:1819, 7bbd09047bd7)
• This PR remains renderer-local: The PR head changes buildExecApprovalPendingReplyPayload so any non-always or missing ask falls to the non-persistable message, while the branch does not update the producers/callers that omit ask. (src/infra/exec-approval-reply.ts:380, 0e9b6735cc8b)
• Current Telegram callers omit ask: Current main builds Telegram approval payloads from filtered actions/decisions but does not pass ask, which is the concrete path that makes this PR unsafe as a standalone fix. (extensions/telegram/src/approval-handler.runtime.ts:75, 7bbd09047bd7)
• Other prompt surfaces remain policy-only: Current main still uses the old policy-only wording in agent-facing pending exec output, Control UI warning text, reaction/manual prompts, and gateway validation; this branch does not cover those sibling surfaces. (src/agents/bash-tools.exec-runtime.ts:403, 7bbd09047bd7)
• Superseding PR is viable: fix(approval): distinguish policy vs non-persistable reason for missing allow-always (fixes #97069) (AI-assisted) #97077 is open, mergeable, labeled proof-sufficient/ready for maintainer look, and its diff threads ask through agent/tool-result, Telegram, reaction, UI, and i18n surfaces for the same linked bug. (97301db93ca8)

Likely related people:

• gumadeiras: Authored the effective exec approval reporting/actions change that added the generic unavailable Allow Always copy across shared approval surfaces. (role: introduced effective-policy approval prompt 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)
• jesse-merhi: Authored the Tree-sitter command authorization planner work that introduced one-shot persistence and unavailable-decision behavior for unpersistable command shapes. (role: one-shot approval behavior contributor; confidence: high; commits: c9707ab635b9; files: src/infra/exec-approvals.ts, src/agents/bash-tools.exec-host-gateway.ts, src/agents/bash-tools.exec-host-node.ts)
• steipete: Current blame and recent history show shared approval reply/forwarder lines carried through recent adjacent approval infrastructure work. (role: recent area contributor; confidence: medium; commits: 56259606d15f; files: src/infra/exec-approval-reply.ts, src/infra/exec-approval-forwarder.ts, src/infra/exec-approvals.ts)

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