fix(approval): distinguish policy vs non-persistable reason when Allow Always unavailable by SunnyShu0925 · Pull Request #97145 · openclaw/openclaw

SunnyShu0925 · 2026-06-27T01:57:54Z

What Problem This Solves

Fixes an issue where users running commands with shell redirection (e.g. openclaw --version 2>&1) would see "The effective approval policy requires approval every time, so Allow Always is unavailable" — even when their effective policy is ask=on-miss. All nine approval prompt renderers (reply, forwarder, agent-facing, Control UI, reaction, embedded handler, Telegram handler, Telegram forwarding, and gateway API) blamed the policy instead of the real cause: the command is non-persistable and cannot be saved as an allow-always rule.

Why This Change Was Made

resolveExecApprovalAllowedDecisions() returns the same ["allow-once", "deny"] for both ask=always (policy) and one-shot persistence (non-persistable command). Downstream renderers had no way to distinguish the two cases.

Rather than introducing a new typed protocol field (which previous attempts attempted across 65+ files), we thread the existing ask field — already present in the request payload, approval view, and gateway pipeline — through the approval-pending data pipeline so renderers can branch on it. Approval policy logic is unchanged.

The node host path uses approvalDecisionAsk (maxAsk(hostAsk, nodeAsk)) to keep the reasoning consistent with allowedDecisions computation even when the node policy is stricter than the host policy.

User Impact

Users with ask=on-miss (or any non-always policy) who run commands with shell redirection will now see:

Allow Always is unavailable because this command cannot be persisted (e.g., shell redirection or dynamic content).

Instead of the misleading policy message. Users with ask=always see the same policy message as before. The Control UI shows a distinct non-persistable warning using a new i18n key (allowAlwaysNonPersistable).

`ask` input	Message shown
`"always"`	"The effective approval policy requires approval every time…"
`"on-miss"` (one-shot)	"Allow Always is unavailable because this command cannot be persisted…"
`"off"` (shell redirect)	"Allow Always is unavailable because this command cannot be persisted…"
absent / null	"The effective approval policy requires approval every time…" (safe default)

Evidence

18 files, +109/−23 lines. Core logic is 52 lines; tests add 57 lines.

Renderers fixed (all 9): reply, forwarder, agent-facing, Control UI, reaction, embedded handler, Telegram handler, Telegram forwarding, gateway API error message.

Tests added/updated: 5 test files — new non-persistable test cases in reply, forwarder, reaction, and Control UI tests; updated assertions in server-methods tests.

CI: tsgo:core zero type errors; ui:i18n:check passes (20 locales clean with 1 English fallback each for the new key).

clawsweeper · 2026-06-27T01:59:07Z

Codex review: needs maintainer review before merge. Reviewed July 12, 2026, 10:42 PM ET / July 13, 2026, 02:42 UTC.

Summary
Threads effective exec-approval ask context through gateway, agent, Telegram, reaction, and Control UI renderers so policy-driven and non-persistable Allow Always exclusions show different explanations, with regression tests and synchronized i18n outputs.

PR surface: Source +132, Tests +79. Total +211 across 59 files.

Reproducibility: yes. at source and proof level: ask=on-miss plus a non-persistable redirected command excludes Allow Always, and the native Telegram before/after evidence demonstrates the wording change. This cycle did not execute a fresh current-head reproduction because checkout commands were blocked before execution.

Review metrics: 2 noteworthy metrics.

Approval reason surface: 2 reason classes across 9 renderers. The merge must keep policy-driven and non-persistable explanations consistent across every user-visible and API-facing approval surface.
Control UI i18n key: 1 key added with 20 locale fallbacks. A rebase or regeneration can silently desynchronize locale source files and generated metadata, which was the repeated prior blocker.

Stored data model
Persistent data-model change detected: serialized state: src/agents/bash-tools.exec-runtime.ts, serialized state: src/gateway/server-methods/exec-approval.ts, serialized state: src/infra/exec-approval-forwarder.test.ts, serialized state: src/infra/exec-approval-forwarder.ts, serialized state: src/infra/exec-approval-reply.test.ts, serialized state: src/infra/exec-approval-reply.ts, and 24 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #97069
Summary: This PR is the remaining open candidate for the approval-message bug; the sibling implementation PRs were closed unmerged and are superseded as landing candidates, while the linked issue is already closed.

Members:

canonical: [Bug]: Approval prompt wrongly says effective policy requires approval every time for non-persistable redirected command #97069 - The issue defines the exact redirected-command approval wording bug this PR addresses.
superseded: fix(approval): distinguish policy vs non-persistable reason for missing allow-always (fixes #97069) (AI-assisted) #97077 - It proposed the same ask-aware wording but is closed unmerged and is not a viable canonical landing path.
superseded: [codex] Explain one-shot exec approval prompts #97081 - It proposed a broader typed protocol reason but is closed unmerged.
superseded: fix(exec): distinguish one-shot from ask=always in approval prompt #97106 - It covered only narrower reply/forwarder surfaces and is closed unmerged.
superseded: fix #97069: [Bug]: Approval prompt wrongly says effective policy requires approval for one-shot commands #97188 - It is another closed-unmerged narrow implementation of the same wording distinction.
2 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Rebase onto current main, resolve the dirty merge state, and trigger a fresh review on the new head.
Run the focused approval renderer tests plus the canonical Control UI i18n check after conflict resolution.

Risk before merge

[P1] The branch is currently conflict-marked, so a rebase may change the implementation or regenerate i18n outputs and requires a fresh exact-head review.
[P1] The current ask-based inference assumes every non-always exclusion of allow-always means non-persistability; the supplied context supports that invariant today, but independent current-main sibling inspection was blocked in this cycle.
[P1] The generated locale catalogs intentionally fall back to English for the new key; maintainers should confirm that this matches current Control UI i18n policy after rebasing.

Maintainer options:

Decide the mitigation before merge
Rebase onto current main, resolve conflicts without dropping the synchronized i18n key/meta outputs, then rerun exact-head focused approval-renderer tests and the Control UI i18n check before ordinary merge review.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P2] The contributor should first produce a clean rebased head; maintainers then need an exact-head review rather than an automated code repair because the present blocker is merge conflict state, not a proven line-level defect.

Maintainer decision needed

Question: After the contributor rebases this conflict-marked branch, does the exact merged shape still preserve the ask-based invariant and canonical generated i18n outputs across all approval surfaces?
Rationale: The patch and proof are strong, but the dirty merge state means the reviewed head is not the final merge result, and this cycle could not independently inspect the checkout due to a sandbox failure.
Likely owner: NianJiuZst — Their prior comprehensive implementation covered the broadest set of affected approval owner boundaries and dependency-contract review.
Options:
- Require clean rebase and fresh review (recommended): Have the contributor rebase, resolve conflicts, rerun focused approval and i18n validation, and trigger a fresh ClawSweeper review on the resulting head.
- Maintainer resolves conflicts: A maintainer may adopt the branch and resolve conflicts, but should still obtain exact-head approval-path and i18n proof before merging.
- Close in favor of a replacement: Close only if maintainers prefer a new clean branch that preserves the same proven behavior and tests rather than repairing this conflicted head.

Security
Cleared: The supplied diff changes approval explanation data flow and UI copy without changing allowed decisions, permissions, secrets, dependencies, workflows, or executable supply-chain inputs.

Review details

Best possible solution:

Rebase onto current main, resolve conflicts without dropping the synchronized i18n key/meta outputs, then rerun exact-head focused approval-renderer tests and the Control UI i18n check before ordinary merge review.

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

Yes at source and proof level: ask=on-miss plus a non-persistable redirected command excludes Allow Always, and the native Telegram before/after evidence demonstrates the wording change. This cycle did not execute a fresh current-head reproduction because checkout commands were blocked before execution.

Is this the best way to solve the issue?

Yes, provisionally: reusing the already-carried effective ask value is narrower than adding a parallel protocol reason and the patch covers the known renderers; final confidence requires confirming the invariant and regenerated i18n state after the conflict-resolving rebase.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (recording): Mantis supplied passing native Telegram Desktop before/after screenshots and recordings that directly show the changed approval prompt wording; the prepared local media manifest could not be opened because the shell sandbox failed, but the hydrated proof report includes concrete run, artifact, baseline, candidate, and outcome details.
remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

P2: This is a bounded user-facing approval-message correctness fix with broad renderer coverage but no change to approval authorization behavior.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (recording): Mantis supplied passing native Telegram Desktop before/after screenshots and recordings that directly show the changed approval prompt wording; the prepared local media manifest could not be opened because the shell sandbox failed, but the hydrated proof report includes concrete run, artifact, baseline, candidate, and outcome details.
proof: sufficient: Contributor real behavior proof is sufficient. Mantis supplied passing native Telegram Desktop before/after screenshots and recordings that directly show the changed approval prompt wording; the prepared local media manifest could not be opened because the shell sandbox failed, but the hydrated proof report includes concrete run, artifact, baseline, candidate, and outcome details.
proof: 🎥 video: Contributor real behavior proof includes video or recording evidence. Mantis supplied passing native Telegram Desktop before/after screenshots and recordings that directly show the changed approval prompt wording; the prepared local media manifest could not be opened because the shell sandbox failed, but the hydrated proof report includes concrete run, artifact, baseline, candidate, and outcome details.
mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The approval explanation is directly visible in Telegram chat, and native Telegram Desktop proof has already been captured for the changed behavior.

Evidence reviewed

PR surface:

Source +132, Tests +79. Total +211 across 59 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	54	230	98	+132
Tests	5	85	6	+79
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	59	315	104	+211

What I checked:

Current head addresses prior blocker: The latest branch commit is specifically chore: sync Control UI i18n outputs for allowAlwaysNonPersistable key, and the provided diff now includes the English key, locale fallback values, and matching generated .meta.json source hashes and key counts; this directly targets the prior review’s generated-i18n finding. (ui/src/i18n/locales/en.ts:1248, 87cc790af31b)
Cross-surface implementation: The patch carries the effective ask value from gateway/node approval construction through pending tool details and into reply, forwarder, reaction, Telegram, gateway error, and Control UI rendering paths, while preserving approvalDecisionAsk for stricter node policy composition. (src/agents/bash-tools.exec-host-node.ts:241, 87cc790af31b)
Focused regression coverage: The supplied diff adds policy-versus-non-persistable assertions in reply, forwarder, reaction, gateway, and Control UI tests, covering both the changed copy and preservation of policy wording. (src/infra/exec-approval-reply.test.ts:421, 87cc790af31b)
Native behavior proof: Mantis reported passing before/after native Telegram Desktop proof for baseline d79373fa142eb056709725cee7d450fb4708d76e and candidate f51358d912da967148b67cad35ffeb43c4ea4ea0, with screenshots, GIFs, MP4s, and a successful overall result. (extensions/telegram/src/approval-handler.runtime.ts:90, f51358d912da)
Current merge state: The provided live PR snapshot reports mergeable: false and mergeableState: dirty at head 87cc790af31b66e712a0851617005bfae7245017, so the branch cannot proceed to ordinary merge review until conflicts are resolved and the exact rebased head is re-reviewed. (87cc790af31b)
Read-only inspection failure: Both attempted checkout reads failed before command execution with bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted; therefore this cycle cannot independently verify the full current diff, scoped AGENTS files, maintainer notes, git history, or media manifest.

Likely related people:

NianJiuZst: Authored the earlier comprehensive approval-reason implementation that traced gateway protocol, exec hosts, renderers, tests, and Codex contract boundaries for the same user problem. (role: recent approval-path contributor; confidence: medium; commits: 4588eb88a160; files: src/infra/exec-approval-reply.ts, src/gateway/server-methods/exec-approval.ts, src/plugin-sdk/approval-reaction-runtime.ts)
jiahjian: Previously implemented the same cross-surface ask-aware wording path across agent, Telegram, reaction, and reply renderers, making them relevant for review of invariant coverage. (role: adjacent approval-rendering contributor; confidence: medium; commits: 1ca163557dd0; files: src/agents/bash-tools.exec-runtime.ts, extensions/telegram/src/approval-handler.runtime.ts, src/infra/exec-approval-reply.ts)
qingminglong: Authored a typed-reason alternative for the same bug across gateway, approval view, embedded reconstruction, and Control UI, providing relevant history on the owner boundaries considered. (role: adjacent approval-model contributor; confidence: medium; commits: 732f7c5a472e; files: src/gateway/server-methods/exec-approval.ts, src/agents/embedded-agent-subscribe.handlers.tools.ts, ui/src/components/exec-approval.ts)

What the crustacean ranks mean

🦀 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.

How this review workflow works

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.

Review history (18 earlier review cycles; latest 8 shown)

reviewed 2026-07-12T08:55:10.710Z sha eeb81b8 :: needs changes before merge. :: [P1] Add ask to the pending-message parameter type | [P1] Restore the non-persistable Control UI warning
reviewed 2026-07-12T09:51:27.383Z sha f51358d :: needs changes before merge. :: [P2] Update the Control UI regression cases for both reasons | [P2] Synchronize the new warning across locale catalogs | [P3] Format the changed approval regression tests
reviewed 2026-07-12T14:17:28.827Z sha 7b48f3d :: needs changes before merge. :: [P2] Remove the generated English locale fallbacks
reviewed 2026-07-12T17:18:32.836Z sha 7b48f3d :: needs changes before merge. :: [P2] Remove the generated English locale fallbacks
reviewed 2026-07-13T00:01:50.934Z sha 9bd627b :: needs changes before merge. :: [P2] Regenerate the canonical Control UI i18n outputs
reviewed 2026-07-13T00:57:27.461Z sha b50c23d :: needs changes before merge. :: [P2] Regenerate the canonical Control UI i18n outputs
reviewed 2026-07-13T01:19:39.203Z sha 257308b :: needs changes before merge. :: [P2] Regenerate the canonical Control UI i18n outputs
reviewed 2026-07-13T01:53:00.981Z sha 257308b :: needs changes before merge. :: [P2] Regenerate the canonical Control UI i18n outputs

SunnyShu0925 · 2026-07-09T22:51:18Z

Rebased on latest origin/main (resolved i18n conflicts by regenerating meta files).

This PR touches 57 files across 4 layers. If the size blocks review, I can split it into smaller, independently reviewable PRs:

Core types + decision logic (exec-types.ts, exec-approval-reply.ts, exec-approval-forwarder.ts, exec-host-shared.ts + tests) — ~6 files
Gateway + agent plumbing (exec-approval.ts, exec-host-gateway.ts, exec-host-node.ts, exec-runtime.ts) — ~5 files
Renderers (Telegram, plugin SDK reaction, UI component) — ~6 files
i18n (38 translation files, mechanical)

Let me know if you prefer the split — happy to close this and open the smaller ones.

lwy-2 · 2026-07-11T02:34:32Z

I rebased this PR onto the latest main and resolved conflicts (all i18n .meta.json conflicts resolved by taking upstream, since those are auto-generated). The rebased branch is at lwy-2:pr-97145-clean.

Rebase was clean: 37 files, +159/−16 lines
Only core code changes (i18n .meta.json changes from the original PR were already present in upstream)
The i18n meta files may need regeneration for the new allowAlwaysNonPersistable key

Feel free to pull my branch or let me know if I can help further.

SunnyShu0925 · 2026-07-12T14:09:48Z

@clawsweeper re-review

clawsweeper · 2026-07-12T14:09:51Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review published an exact durable review comment and queued an exact-item serialized router run.
Run: https://github.com/openclaw/clawsweeper/actions/runs/29201580629
Updated: 2026-07-12T17:20:19.955Z

…w Always unavailable

clawsweeper · 2026-07-13T01:44:25Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review published an exact durable review comment and queued an exact-item serialized router run.
Run: https://github.com/openclaw/clawsweeper/actions/runs/29218136581
Updated: 2026-07-13T01:54:55.443Z

SunnyShu0925 · 2026-07-13T02:24:35Z

@clawsweeper re-review

clawsweeper · 2026-07-13T02:24:38Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review published an exact durable review comment and queued an exact-item serialized router run.
Run: https://github.com/openclaw/clawsweeper/actions/runs/29219945488
Updated: 2026-07-13T02:43:56.812Z

SunnyShu0925 · 2026-07-13T02:52:34Z

This PR has been tagged with status: 👀 ready for maintainer look, proof: sufficient, proof: 🎥 video, and rating: 🐚 platinum hermit — it appears to meet the merge-ready bar from the ClawSweeper side. However, it currently has merge conflicts that will need to be resolved before landing.

@vincentkoc, when you have a moment, could you please take a look and review? Thanks!

SunnyShu0925 · 2026-07-13T02:56:24Z

This PR has been superseded by #97740, which was merged by @vincentkoc on July 11, 2026 to fix the same issue (#97069).

The two PRs took different approaches:

fix(approval): distinguish policy vs non-persistable reason when Allow Always unavailable #97145 (this PR): threaded the ask field through the approval pipeline to distinguish policy vs non-persistable causes, with a dedicated allowAlwaysNonPersistable i18n key
fix(exec-approval): stop misattributing Allow Always unavailability to policy #97740: took a lighter approach, replacing the misleading policy-blaming text with a neutral "Allow Always is unavailable for this command." across all renderers

Since #97740 has already been merged and resolved the issue, closing this PR as superseded. Thank you @SunnyShu0925 for the contribution — the deeper approach may still be valuable reference if more granular unavailable-reason messaging is pursued in the future.

SunnyShu0925 · 2026-07-13T02:56:26Z

Closed as superseded by #97740.

openclaw-barnacle Bot added app: web-ui App: web-ui agents Agent runtime and tooling size: M labels Jun 27, 2026

SunnyShu0925 force-pushed the fix/exec-approval-prompt-text-97069 branch from 02058fe to 66ae5f7 Compare June 27, 2026 02:03

clawsweeper Bot had a problem deploying to qa-live-shared June 27, 2026 02:07 Failure

SunnyShu0925 force-pushed the fix/exec-approval-prompt-text-97069 branch from 66ae5f7 to fa5b811 Compare June 27, 2026 02:10

clawsweeper Bot added P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 other 🚨 Merging this PR has meaningful risk outside the owned taxonomy. labels Jun 27, 2026

SunnyShu0925 force-pushed the fix/exec-approval-prompt-text-97069 branch from fa5b811 to 7bf87f2 Compare June 27, 2026 02:20

openclaw-barnacle Bot added channel: telegram Channel integration: telegram gateway Gateway runtime labels Jun 27, 2026

clawsweeper Bot removed proof: sufficient ClawSweeper judged the real behavior proof convincing. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. labels Jun 27, 2026

clawsweeper Bot had a problem deploying to qa-live-shared June 30, 2026 09:36 Failure

clawsweeper Bot added rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jun 30, 2026

clawsweeper Bot mentioned this pull request Jul 9, 2026

fix: approval prompt misleading text for one-shot commands #102441

Open

lwy-2 mentioned this pull request Jul 11, 2026

fix: show correct reason when Allow Always is unavailable for one-shot (redirected) commands #104072

Closed

SunnyShu0925 added 5 commits July 13, 2026 07:32

fix(approval): distinguish policy vs non-persistable reason when Allo…

7eef926

…w Always unavailable

fix(ui): restore distinct non-persistable warning in Control UI

9e5e3e2

fix(agents): add ask to buildApprovalPendingMessage params type

9bd627b

fix(ui): add Control UI test for non-persistable warning

b50c23d

chore: format test files (oxfmt)

257308b

chore: sync Control UI i18n outputs for allowAlwaysNonPersistable key

87cc790

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(approval): distinguish policy vs non-persistable reason when Allow Always unavailable#97145

fix(approval): distinguish policy vs non-persistable reason when Allow Always unavailable#97145
SunnyShu0925 wants to merge 6 commits into
openclaw:mainfrom
SunnyShu0925:fix/exec-approval-prompt-text-97069

SunnyShu0925 commented Jun 27, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

Uh oh!

SunnyShu0925 commented Jul 9, 2026

Uh oh!

lwy-2 commented Jul 11, 2026

Uh oh!

SunnyShu0925 commented Jul 12, 2026

Uh oh!

clawsweeper Bot commented Jul 12, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 13, 2026 •

edited

Loading

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

clawsweeper Bot commented Jul 13, 2026 •

edited

Loading

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

SunnyShu0925 commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SunnyShu0925 commented Jul 9, 2026

Uh oh!

lwy-2 commented Jul 11, 2026

Uh oh!

SunnyShu0925 commented Jul 12, 2026

Uh oh!

clawsweeper Bot commented Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

clawsweeper Bot commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

SunnyShu0925 commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

SunnyShu0925 commented Jun 27, 2026 •

edited

Loading

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

clawsweeper Bot commented Jul 12, 2026 •

edited

Loading

clawsweeper Bot commented Jul 13, 2026 •

edited

Loading

clawsweeper Bot commented Jul 13, 2026 •

edited

Loading