fix(skills): make Skill Workshop lifecycle approvals decidable and non-wedging by steipete · Pull Request #100498 · openclaw/openclaw

steipete · 2026-07-06T00:03:16Z

What Problem This Solves

Agent-initiated Skill Workshop lifecycle actions were effectively broken under the default approval policy, and the approval popup gave operators nothing to decide on:

skill_workshop(action="apply") always timed out: the approval wait defaulted to 120s while the Codex dynamic-tool watchdog kills the call at 90s, so the tool call died before any human could decide ([Bug]: Skill Workshop agent-tool apply times out because approval wait exceeds tool watchdog #91266, consistently reproduced on large proposals in skill_workshop apply times out ("Approval timed out") on large proposals (~28KB) #94249).
The approval popup showed only fixed text — no proposal id, skill name, description, or size — forcing operators into openclaw skills workshop inspect just to know what they are approving (Skill Workshop apply popup carries no proposal details + fixed 60s TTL #93173).
On timeout the agent got a bare "Approval timed out" failure, reading like an error and inviting retry loops even though the proposal was safely pending.

Closes #91266. Closes #94249. Closes #93173.

Why This Change Was Made

Approval wait bounded inside the tool budget (src/skills/workshop/policy.ts): workshop lifecycle approvals now set timeoutMs: 70_000. The Codex dynamic-tool watchdog is 90s (extensions/codex/src/app-server/dynamic-tool-execution.ts:23); the gateway approval RPC reserves +10s cleanup grace, leaving 10s headroom — the tool call now always returns before the watchdog fires. A static bound is required because the upstream Codex dynamic-tool contract carries no deadline: verified directly in codex-rs/app-server-protocol/src/protocol/v2/item.rs (DynamicToolCallParams = thread/turn/call ids + tool + arguments only) and codex-rs/app-server/src/dynamic_tools.rs (no deadline plumbing) at codex be33f80bc6.

Approval requests carry proposal metadata: the policy resolver loads the pending proposal (by proposal_id, or name via the same resolution the tool uses) and builds the description with proposal id, target skill name, the 160-byte proposal description, support-file count, and body size in KB. Control/format characters are rendered inert and long names bounded, so proposal-controlled text cannot spoof the approval card. Unresolvable proposals fall back to today's static text. This enriches every approval surface (Control UI popup, chat approval card) with zero UI-component changes. PLUGIN_APPROVAL_DESCRIPTION_MAX_LENGTH raised 256 → 512 (validation loosening, additive for protocol consumers) to fit the metadata; workspace scope is threaded through gateway invocation, the Codex approval bridge, dynamic tools, and the native-hook relay so the resolver can read the right store.

Honest, non-wedging timeout outcome: a new optional timeoutReason on the requireApproval shape (used only by the workshop policy) turns approval timeout into a structured blocked (veto) tool result instead of a failure: the request expired without a decision, the proposal is unchanged and still pending, decide via the Skill Workshop UI or openclaw skills workshop apply|reject|quarantine <id>, do not retry in a loop. Generic plugin approval timeouts are untouched. There is deliberately no auto-apply on timeout, and expired requests cannot execute later: the gateway approval manager resolves expired requests to null and rejects late decisions (src/gateway/exec-approval-manager.ts), and the embedded broker deletes pending requests before resolving timeout (src/infra/embedded-plugin-approval-broker.ts).

User Impact

Agent-initiated apply/reject/quarantine now works under the default approval policy: the operator gets ~70s to decide from a popup that actually describes the proposal, and CLI/UI paths remain available afterwards.
No more misleading timeout errors or retry loops; the agent relays exactly what happened and what the operator can do.
Approval behavior for every other plugin is unchanged. No new config keys, no auto-approval paths.
Docs: approval section of skill-workshop updated with what the popup shows and the timeout semantics.

Evidence

Focused suites on Blacksmith Testbox: workshop policy/service, before-tool-call e2e + embedded-mode, gateway plugin-approval, workspace propagation (Codex reported 143 + 360 + 21 tests across the touched surfaces; re-run green on the final tree).
Testbox check:changed: core, core tests, extensions, extension tests, docs — run 28758816731.
Upstream Codex contract personally verified in the sibling codex checkout at be33f80bc6 (files cited above).
Structured second-model review (Codex, gpt-5.5): earlier accepted findings (description bounds, Unicode spoofing, protocol fixture, workspace scoping) fixed; final review clean. One suggestion rejected as scope-expanding: binding the popup snapshot to a proposal revision would require out-of-band state because native Codex rejects approval parameter rewrites (src/agents/harness/native-hook-relay.ts:722) — follow-up territory.
Release-note context: user-facing fix — Skill Workshop approval prompts now show proposal details, fit inside the tool watchdog, and expire into an actionable pending state instead of an error.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1ab67deca7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-07-06T00:08:36Z

  return {
    requireApproval: {
      ...text,
+      description: approvalDescription.description,


Bind approval to the described proposal revision

When a proposal is revised after this metadata is loaded but before the operator clicks allow, the approval still authorizes the original proposal_id only; the later applySkillProposal path re-reads and applies the current proposal content (src/skills/workshop/service.ts:504), while reviseSkillProposal can change the same proposal in place (src/skills/workshop/service.ts:381). In a parallel tool call or another session during the 70s approval window, the operator can approve the displayed description/body size for revision N but apply revision N+1. Include the draft hash/proposed version in the approved params and reject if it changed before executing the lifecycle action.

Useful? React with 👍 / 👎.

clawsweeper · 2026-07-06T00:20:44Z

Codex review: needs real behavior proof before merge. Reviewed July 5, 2026, 10:06 PM ET / 02:06 UTC.

Summary
The PR shortens Skill Workshop lifecycle approval waits, enriches approval descriptions with proposal metadata, returns actionable timeout vetoes, widens plugin approval descriptions to 512 characters, threads workspace context through Codex/Gateway paths, and updates focused tests/docs.

PR surface: Source +118, Tests +216, Docs +8. Total +342 across 17 files.

Reproducibility: yes. at source level: current main has a 120s generic plugin approval wait against a 90s Codex dynamic-tool watchdog, and the PR-introduced stale-metadata path follows from revising a pending proposal before apply re-reads it by id. I did not run a live Gateway/Codex approval session in this read-only review.

Review metrics: 1 noteworthy metric.

Approval contract surfaces: 1 protocol cap widened, 1 hook timeout field added. Approval payloads cross plugin/tool execution into reviewer UI, so the public contract, sibling adapters, and docs need to stay aligned before merge.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦐 gold shrimp
Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

Bind lifecycle approvals to the displayed proposal revision or get an explicit maintainer decision accepting the mutable snapshot risk.
Replace the node-invoke hard-coded 256-character slice with the shared approval description cap and update the public plugin approval docs.
[P1] Add redacted live proof of a Skill Workshop lifecycle approval prompt resolving or expiring through the real agent/Gateway path.

Proof guidance:

[P1] Needs real behavior proof before merge: The PR body lists focused Testbox/CI suites, but I did not find live after-fix proof such as a redacted approval prompt transcript, terminal output, logs, screenshot, or recording of the Skill Workshop approval flow. 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.

Risk before merge

[P1] An operator can approve metadata for one pending proposal revision while the later apply path re-reads and applies a newer revision of the same proposal id.
[P1] Dangerous node-command plugin approvals can silently lose the second half of a newly valid 512-character description because the node-invoke adapter still slices at 256 characters.
[P1] The public plugin permission guide still documents the old 256-character cap, so plugin authors can target stale approval payload limits.
[P1] The PR body lists focused Testbox/CI suites, but it does not include live after-fix proof of an actual Skill Workshop approval prompt and resolution path.

Maintainer options:

Bind And Align Approval Contracts (recommended)
Before merge, bind Skill Workshop lifecycle approvals to the displayed revision and update the node-invoke adapter plus public docs to the shared 512-character approval cap.
Accept The Current Approval Semantics
Maintainers can intentionally accept the mutable-revision window and inconsistent 256-character node approval truncation as known risks for this release.
Pause For Approval API Design
Pause the PR until approval owners choose the revision-binding and plugin-approval surface contract explicitly.

Next step before merge

[P1] Manual review is needed because the remaining blocker is an approval security-boundary decision on revision binding, with smaller mechanical cap/docs repairs after that decision.

Maintainer decision needed

Question: Should Skill Workshop lifecycle approvals be required to apply only the proposal revision whose metadata was shown to the operator?
Rationale: The PR improves approval context, but applying a later in-place revision after approving an earlier prompt changes the approval security boundary, and native Codex parameter rewrite limits make the permanent binding layer a maintainer-owned choice.
Likely owner: steipete — steipete owns the current PR and has recent approval/node-policy history on the affected surfaces.
Options:
- Bind Revision Before Merge (recommended): Require apply, reject, and quarantine to reject or re-prompt if the proposal draftHash or proposedVersion changed after approval metadata was generated.
- Accept Mutable Snapshot: Merge with explicit maintainer acceptance that approval metadata is advisory and may describe a different proposal revision than the one later applied.
- Pause For API Direction: Hold this PR until maintainers choose whether revision binding belongs in tool params, service action input, or approval callback state.

Security
Needs attention: The diff improves approval safety overall, but two approval-security details still need attention before merge.

Review findings

[P2] Bind approval to the described proposal revision — src/skills/workshop/policy.ts:170-172
[P2] Use the shared approval description cap in node policy — src/infra/plugin-approvals.ts:53
[P3] Update the public approval length docs — packages/gateway-protocol/src/schema/plugin-approvals.ts:14

Review details

Best possible solution:

Land the timeout and metadata fix after binding lifecycle approval to the displayed proposal revision, aligning all approval-description caps and docs, and adding a redacted live approval-flow proof.

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

Yes, at source level: current main has a 120s generic plugin approval wait against a 90s Codex dynamic-tool watchdog, and the PR-introduced stale-metadata path follows from revising a pending proposal before apply re-reads it by id. I did not run a live Gateway/Codex approval session in this read-only review.

Is this the best way to solve the issue?

No, not yet: the 70s bounded wait and richer approval metadata are the right layer, but the lifecycle action must be tied to the displayed proposal revision and the approval description cap must be consistent across adapters and docs.

Full review comments:

[P2] Bind approval to the described proposal revision — src/skills/workshop/policy.ts:170-172
The approval description is generated from the proposal before the operator decides, but applySkillProposal later re-reads the current pending record by id. Since reviseSkillProposal updates the same proposal id in place, another session can revise the proposal during the 70s approval window and make the operator approve vN metadata while vN+1 is applied; carry and verify draftHash/proposedVersion, or reject and re-prompt if it changed.
Confidence: 0.9
[P2] Use the shared approval description cap in node policy — src/infra/plugin-approvals.ts:53
The PR raises the approval description contract to 512 characters, but the node-invoke policy adapter still stores input.description.slice(0, 256). Late discovery: this mismatch was unchanged since the previous reviewed head, but it means dangerous node-command approvals can silently drop newly valid risk context while other plugin approval paths preserve it.
Confidence: 0.87
Late finding: first raised on code an earlier review cycle already covered.
[P3] Update the public approval length docs — packages/gateway-protocol/src/schema/plugin-approvals.ts:14
The schema now accepts approval descriptions up to 512 characters, but docs/plugins/plugin-permission-requests.md still tells plugin authors the Gateway caps descriptions at 256. Update the public docs alongside the protocol cap change so plugin authors do not target the old limit.
Confidence: 0.84

Overall correctness: patch is incorrect
Overall confidence: 0.89

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

add merge-risk: 🚨 compatibility: The PR changes public plugin approval contract surfaces while one sibling adapter and public docs still preserve the old 256-character description limit.
add 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 Testbox/CI suites, but I did not find live after-fix proof such as a redacted approval prompt transcript, terminal output, logs, screenshot, or recording of the Skill Workshop approval flow. 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.
remove status: ⏳ waiting on author: Current PR status label is status: 📣 needs proof.

Label justifications:

P2: This is a focused fix for real Skill Workshop agent-tool approval failures with limited blast radius, but it still has merge-blocking approval-boundary issues.
merge-risk: 🚨 security-boundary: The enriched approval prompt can authorize a proposal id whose underlying pending content changed after the metadata was displayed.
merge-risk: 🚨 compatibility: The PR changes public plugin approval contract surfaces while one sibling adapter and public docs still preserve the old 256-character description limit.
rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
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 Testbox/CI suites, but I did not find live after-fix proof such as a redacted approval prompt transcript, terminal output, logs, screenshot, or recording of the Skill Workshop approval flow. 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.

Evidence reviewed

PR surface:

Source +118, Tests +216, Docs +8. Total +342 across 17 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	11	132	14	+118
Tests	5	217	1	+216
Docs	1	8	0	+8
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	17	357	15	+342

Security concerns:

[medium] Approval can apply content different from the prompt — src/skills/workshop/policy.ts:170
The approval prompt describes a proposal snapshot, but pending proposals can be revised in place and the apply path re-reads by id after approval, so the approved metadata may not match the content applied.
Confidence: 0.9
[medium] Node approval descriptions still truncate at 256 — src/gateway/node-invoke-plugin-policy.ts:67
After the PR raises the shared cap to 512, dangerous node-command policy approvals can still lose half of the reviewer-facing risk context on the node-invoke path.
Confidence: 0.87

What I checked:

Current-main bug still exists without this PR: Current main has a 120s default plugin approval wait, no Skill Workshop-specific timeout override, and a 90s Codex dynamic-tool watchdog, matching the linked timeout reports. (src/skills/workshop/policy.ts:47, d095f4755339)
PR prompt metadata is not bound to applied revision: At PR head, the approval description is built from the pending proposal, but the later tool execution still calls apply by proposal id only; no draft hash or version from the displayed snapshot is enforced. (src/skills/workshop/policy.ts:170, e3bd9da2261e)
Proposal revisions mutate in place before apply re-reads: The service updates the same proposal id with a new proposedVersion and draftHash during revise, while apply re-reads the current pending proposal content before writing it. (src/skills/workshop/service.ts:381, e3bd9da2261e)
Approval description cap is inconsistent across sibling surfaces: The PR raises protocol/runtime approval descriptions to 512, but the node-invoke plugin policy adapter still truncates descriptions to 256 before broadcasting the same approval payload. (src/gateway/node-invoke-plugin-policy.ts:67, e3bd9da2261e)
Public docs still describe the old approval description cap: The plugin permission guide still tells plugin authors that Gateway approval descriptions are capped at 256 characters after the PR changes the schema cap to 512. Public docs: docs/plugins/plugin-permission-requests.md. (docs/plugins/plugin-permission-requests.md:80, e3bd9da2261e)
Codex dependency contract checked: The sibling Codex checkout at be33f80 shows DynamicToolCallParams carries ids, namespace, tool, and arguments only, with no deadline field, supporting the PR's bounded-timeout approach. (codex-rs/app-server-protocol/src/protocol/v2/item.rs:1544, be33f80bc651)

Likely related people:

shakkernerd: GitHub commit history shows this handle introduced the Skill Workshop runtime policy and carried later service lifecycle work around proposal revisions and apply. (role: Skill Workshop feature introducer; confidence: high; commits: 3037646d228d, 2383cfd3039d, 34a1102506d8; files: src/skills/workshop/policy.ts, src/skills/workshop/service.ts, src/agents/tools/skill-workshop-tool.ts)
joshavant: Commit history identifies this handle as introducing async before_tool_call requireApproval, plugin approval timeouts, and the approval protocol used by this PR. (role: approval framework contributor; confidence: high; commits: 6ade9c474cf1; files: src/agents/agent-tools.before-tool-call.ts, src/infra/plugin-approvals.ts, packages/gateway-protocol/src/schema/plugin-approvals.ts)
steipete: GitHub history shows recent work on node-invoke policy and plugin approval bounds, and this handle owns the current fix branch beyond merely opening it. (role: recent approval and node-policy contributor; confidence: high; commits: 1fef99962edf, cae98c1daf3e, e3bd9da2261e; files: src/gateway/node-invoke-plugin-policy.ts, src/infra/plugin-approvals.ts, src/skills/workshop/policy.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 (1 earlier review cycle)

reviewed 2026-07-06T00:26:24.538Z sha 1ab67de :: needs real behavior proof before merge. :: [P2] Bind approval to the described proposal revision | [P3] Update the public approval length docs

…n-wedging (#91266, #94249, #93173) Approval wait now fits inside the Codex dynamic-tool watchdog (70s +10s gateway grace under the 90s kill), approval cards carry proposal id, skill name, description, file count, and body size (spoof-safe rendering), and timeouts return a structured pending-not-failed outcome instead of a bare error. Expired requests cannot execute late; no auto-apply; generic plugin approvals unchanged.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e3bd9da226

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-07-06T01:54:30Z

 export const MAX_PLUGIN_APPROVAL_TIMEOUT_MS = 600_000;
 export const PLUGIN_APPROVAL_TITLE_MAX_LENGTH = 80;
-export const PLUGIN_APPROVAL_DESCRIPTION_MAX_LENGTH = 256;
+export const PLUGIN_APPROVAL_DESCRIPTION_MAX_LENGTH = 512;


Use the shared 512-char cap for node approvals

This raises the plugin approval description contract to 512 characters, but the node-invoke policy approval adapter still does input.description.slice(0, 256) in src/gateway/node-invoke-plugin-policy.ts:67 before storing and broadcasting the same PluginApprovalRequestPayload. For dangerous node commands whose policies use the newly allowed extra room to explain the target/risk, reviewers on that path will silently lose the second half of the approval context while other plugin approval paths preserve it; update the adapter to use the shared limit instead of the old hard-coded cap.

Useful? React with 👍 / 👎.

…n-wedging (openclaw#91266, openclaw#94249, openclaw#93173) (openclaw#100498) Approval wait now fits inside the Codex dynamic-tool watchdog (70s +10s gateway grace under the 90s kill), approval cards carry proposal id, skill name, description, file count, and body size (spoof-safe rendering), and timeouts return a structured pending-not-failed outcome instead of a bare error. Expired requests cannot execute late; no auto-apply; generic plugin approvals unchanged.

openclaw-barnacle Bot added docs Improvements or additions to documentation app: web-ui App: web-ui gateway Gateway runtime agents Agent runtime and tooling extensions: codex size: M maintainer Maintainer-authored PR labels Jul 6, 2026

chatgpt-codex-connector Bot reviewed Jul 6, 2026

View reviewed changes

steipete force-pushed the fix/workshop-approval-flow-65fd03 branch from 1ab67de to e3bd9da Compare July 6, 2026 01:47

chatgpt-codex-connector Bot reviewed Jul 6, 2026

View reviewed changes

steipete merged commit f53103d into main Jul 6, 2026
116 of 120 checks passed

steipete deleted the fix/workshop-approval-flow-65fd03 branch July 6, 2026 03:54

clawsweeper Bot mentioned this pull request Jul 6, 2026

[Bug]: Non-message inbound channel hooks (like reactions/clicks) drop event context metadata #100626

Closed

steipete mentioned this pull request Jul 9, 2026

fix(workshop): keep approval target names UTF-16 safe #102963

Merged

clawsweeper Bot mentioned this pull request Jul 12, 2026

skill_workshop apply hangs indefinitely in long-lived gateway (in-process lock chain wedges); fresh-process CLI apply works #105152

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(skills): make Skill Workshop lifecycle approvals decidable and non-wedging#100498

fix(skills): make Skill Workshop lifecycle approvals decidable and non-wedging#100498
steipete merged 1 commit into
mainfrom
fix/workshop-approval-flow-65fd03

steipete commented Jul 6, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Jul 6, 2026

Uh oh!

clawsweeper Bot commented Jul 6, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Jul 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

steipete commented Jul 6, 2026

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Jul 6, 2026 •

edited

Loading