fix: block mixed-case cron shell jobs from agent tool [AI] by pgondhi987 · Pull Request #101350 · openclaw/openclaw

pgondhi987 · 2026-07-07T04:17:49Z

What Problem This Solves

Agent-created cron jobs could bypass the cron tool's shell-execution restriction by sending payload.kind: "Command". The tool checked for the exact lowercase spelling before cron normalization later canonicalized the payload to an executable command job.

Why This Change Was Made

The agent cron tool now applies the existing lowercase-string normalizer at its command-payload deny boundary for both add and update. The change intentionally leaves the separate on-exit guard unchanged: cron tool canonicalization already converts a schedule containing command to on-exit before this guard, including mixed-case input.

User Impact

Agent and MCP tool calls can no longer create or edit command-backed cron jobs by changing the casing of the payload kind. CLI and direct Gateway cron APIs retain their existing command-job support.

Evidence

Sanitized AWS Crabbox baseline run run_21427c843258 combined the regression tests with current main; both mixed-case command add/update cases failed as expected before the fix.
Sanitized AWS Crabbox baseline run run_beacbda457f9 proved mixed-case on-exit add/update were already rejected on current main (2/2 passed), so the redundant on-exit change was removed.
Sanitized AWS Crabbox exact-head run run_b62a042cc371, provider aws, lease cbx_e4653c3a8908: pnpm test src/agents/tools/cron-tool.test.ts passed 142/142 tests.
git diff --check passed.
Structured autoreview on exact head efcdfa377123298cea8f4cf3c17cfad82775ecff was clean with 0.91 confidence.

pgondhi987 · 2026-07-07T04:30:24Z

ClawSweeper proof for current head 3c3dbf2

Behavior proved: the agent-facing cron tool now denies shell-backed cron jobs even when payload.kind or schedule.kind uses alternate casing. The protected boundary is the agent/tool-policy boundary before cron.add or cron.update; the protected sink is the Gateway cron command execution path that can eventually run runCommandWithTimeout for trusted Gateway/CLI-created command cron jobs.

Environment: local PR checkout plus GitHub Actions PR CI for the exact current head. The local proof exercises createCronTool(...).execute(...), which is the same production cron tool executor used by the agent tool and stdio MCP tool handler; the Gateway call is stubbed so the proof can assert whether the protected sink is reached.

Command/artifact:

node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts in the issue worktree: 1 file, 144 tests passed.
node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts in the review worktree: 1 file, 144 tests passed.
git diff --check in the issue worktree: passed.
GitHub statusCheckRollup for head 3c3dbf2c3a2e9285b86ccf32f8168fc55d0825a2: no failing or pending relevant checks; CI checks completed successfully/skipped/neutral.

Evidence:

Fixed/denied scenario: the regression tests call the cron tool add and update paths with mixed-case payload.kind: "Command" and mixed-case schedule.kind: "On-Exit". Each case throws the existing cron command/on-exit denial error, and the tests assert the Gateway call mock is not called. Protected sink result: zero cron.add / cron.update calls for the denied shell-backed inputs, so the command execution sink is not reached from the agent tool.
Positive control: the same cron tool suite still passes the existing allowed agent cron cases, including normal agentTurn cron creation/update paths that expect cron.add / cron.update to be called. Intended behavior preserved: regular reminder-style cron jobs still dispatch through the cron tool, while shell-backed command/on-exit jobs remain reserved for the trusted CLI/Gateway API surface.

Compatibility/operator note: this changes only agent-tool behavior for already-forbidden command/on-exit cron jobs. It does not change cron schemas, persisted cron data, config/defaults, or the trusted CLI/Gateway command-cron path.

Live gaps: I inspected issue-appropriate package scripts and found cron Docker/integration lanes (test:docker:cron-cli, test:docker:cron-mcp-cleanup). They were not run because the remote proof backends available to this session are blocked before source sync: Testbox requires Crabbox newer than the installed 0.20.0 binary, and direct AWS Crabbox is not logged in on this host. No live provider, native client, browser, Telegram, or screenshot proof is required for this cron tool boundary.

pgondhi987 · 2026-07-07T04:30:25Z

@clawsweeper re-review

clawsweeper · 2026-07-07T04:30:28Z

🦞🧹
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.

clawsweeper · 2026-07-07T04:58:35Z

Codex review: needs maintainer review before merge. Reviewed July 7, 2026, 1:28 AM ET / 05:28 UTC.

Summary
The PR normalizes cron payload and schedule kind values in the agent cron tool shell-execution guard and adds mixed-case add/update regression cases.

PR surface: Source 0, Tests +12. Total +12 across 2 files.

Reproducibility: yes. from source inspection: current main checks raw lowercase strings before cron normalization lowercases kind values, so Command and On-Exit can pass the agent-tool guard. I did not run a current-main failing command in this read-only review.

Review metrics: 1 noteworthy metric.

Denied shell-kind scenarios: 4 add/update cases covered. The regression coverage and terminal proof cover command payload and on-exit schedule denial on both add and update.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🦞 diamond lobster
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:

Refresh the branch so final CI runs against current main before landing.

Risk before merge

[P1] This intentionally fail-closes mixed-case Command/On-Exit attempts through the agent cron tool; that path was already forbidden by policy, while trusted CLI/Gateway command cron remains supported.
[P1] The live PR is mergeable but behind current main, so final landing should refresh exact-head checks.

Maintainer options:

Accept the boundary tightening (recommended)
Merge after exact-head checks, accepting that agent-tool mixed-case command/on-exit cron attempts now fail as intended while trusted CLI/Gateway command cron remains supported.
Ask for broader runtime proof
Request a full agent-to-Gateway transcript before merge if maintainers want proof beyond the direct production executor denial path.

Next step before merge

[P2] The patch has no blocking findings and proof is now sufficient, but the protected maintainer label, stale base, and shell-execution boundary make this a maintainer merge decision rather than a repair-lane item.

Maintainer decision needed

Question: Should maintainers accept the intentional fail-closed agent-tool behavior for mixed-case command/on-exit cron kinds and land this boundary hardening after exact-head checks?
Rationale: The patch and proof are strong, but it touches a shell-execution boundary, intentionally blocks an unsupported bypass, and carries a protected maintainer label.
Likely owner: steipete — They are the clearest current-source routing candidate for the touched guard/normalizer boundary.
Options:
- Accept and land after refresh (recommended): Accept the boundary tightening, rebase or refresh exact-head checks, and merge if CI remains clean.
- Require broader runtime proof: Ask for a full agent-to-Gateway transcript if direct production-executor proof is not enough for this boundary.
- Pause for boundary redesign: Pause only if maintainers want command cron creation exposed through a different explicit agent-safe API.

Security
Cleared: The diff tightens an existing shell-execution boundary and does not add dependencies, workflows, secrets handling, or new code-execution surfaces.

Review details

Best possible solution:

Land the narrow agent-tool boundary hardening after current-head checks, preserving the trusted CLI/Gateway command cron path.

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

Yes from source inspection: current main checks raw lowercase strings before cron normalization lowercases kind values, so Command and On-Exit can pass the agent-tool guard. I did not run a current-main failing command in this read-only review.

Is this the best way to solve the issue?

Yes. The PR fixes the existing agent-tool denial point with the same normalization helper used by cron normalization; moving the denial into Gateway cron would risk blocking the trusted CLI/Gateway command-cron path.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

add merge-risk: 🚨 compatibility: Merging intentionally changes any setup relying on the mixed-case agent-tool bypass from accepted to denied.
add proof: sufficient: Contributor real behavior proof is sufficient. The PR body and comments include after-fix terminal output from the production cron tool executor showing mixed-case command/on-exit add and update inputs denied before Gateway dispatch.
add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body and comments include after-fix terminal output from the production cron tool executor showing mixed-case command/on-exit add and update inputs denied before Gateway dispatch.
remove rating: 🦪 silver shellfish: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

P0: The PR hardens an agent-tool shell-execution policy boundary before command cron jobs can reach the Gateway command runner.
merge-risk: 🚨 compatibility: Merging intentionally changes any setup relying on the mixed-case agent-tool bypass from accepted to denied.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body and comments include after-fix terminal output from the production cron tool executor showing mixed-case command/on-exit add and update inputs denied before Gateway dispatch.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body and comments include after-fix terminal output from the production cron tool executor showing mixed-case command/on-exit add and update inputs denied before Gateway dispatch.

Evidence reviewed

PR surface:

Source 0, Tests +12. Total +12 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	2	2	0
Tests	1	20	8	+12
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	22	10	+12

What I checked:

Current main guard is case-sensitive: Current main checks raw payload.kind === "command" and schedule.kind === "on-exit" before forwarding cron add/update calls, so alternate casing is not caught at the agent-tool guard. (src/agents/tools/cron-tool.ts:447, 01d6ea1f0e87)
Cron normalization is already case-insensitive: The shared cron normalizer lowercases schedule kinds and maps lowercased command payload kinds to canonical command, which makes the current-main raw guard the wrong boundary for mixed-case input. (src/cron/normalize.ts:97, 01d6ea1f0e87)
Patch fixes the existing guard point: The PR changes only the agent cron tool guard comparisons to use normalizeLowercaseStringOrEmpty, leaving CLI/Gateway cron command support unchanged. (src/agents/tools/cron-tool.ts:447, 3c3dbf2c3a2e)
Agent entry point and command sink checked: Agent tools instantiate createCronTool, while command cron jobs can later reach runCommandWithTimeout through runCronCommandJob; the PR blocks before cron.add/cron.update dispatch from the agent tool. (src/cron/command-runner.ts:101, 01d6ea1f0e87)
Regression coverage targets the denied paths: The diff extends add and update tests for mixed-case command payloads and on-exit schedules and asserts the Gateway mock is not called. (src/agents/tools/cron-tool.test.ts:1046, 3c3dbf2c3a2e)
Real behavior proof was updated: The PR body and follow-up comment include terminal output from createCronTool().execute(...) showing four mixed-case shell-backed add/update inputs denied before Gateway dispatch. (3c3dbf2c3a2e)

Likely related people:

steipete: Current checkout blame points the guard and normalizer lines to Peter Steinberger, and nearby history includes cron lowercase-helper refactoring. (role: recent area contributor; confidence: medium; commits: ae16704864d0, 934927fd13ed; files: src/agents/tools/cron-tool.ts, src/cron/normalize.ts)
mbelinky: They authored the merged command cron jobs work that created the trusted command payload path adjacent to this guard. (role: feature introducer; confidence: high; commits: 1b97e65681ec, d5f6215e3437, dca88c907484; files: src/cron/command-runner.ts, src/cron/service/timer.ts, src/agents/tools/cron-tool.ts)
vincentkoc: They merged the command cron jobs PR and authored follow-up process-tree hardening in the command execution path. (role: merger and adjacent command-cron contributor; confidence: medium; commits: 1fa471349f8a, 0f802edc2b37; files: src/cron/command-runner.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-07T05:04:02.516Z sha 3c3dbf2 :: needs real behavior proof before merge. :: none

pgondhi987 · 2026-07-07T05:07:57Z

ClawSweeper proof for current head 3c3dbf2

Behavior proved: the agent-facing cron tool denies shell-backed cron jobs even when payload.kind or schedule.kind uses alternate casing. The protected security boundary is the agent/tool-policy boundary before cron.add or cron.update; the protected sink is the Gateway cron command execution path that can eventually run runCommandWithTimeout for trusted Gateway/CLI-created command cron jobs.

Real environment and entry point: local checkout at the current PR head plus GitHub Actions PR CI. The denied-path terminal proof uses createCronTool().execute(...) without a mocked Gateway. That is the real cron tool executor used by the agent tool and stdio MCP tool handler; because the denied calls throw the cron-tool policy error before Gateway dispatch, the protected Gateway sink is not reached.

Exact commands and artifacts:

node --import tsx --eval 'async function main() { const { createCronTool } = await import("./src/agents/tools/cron-tool.ts"); const tool = createCronTool(); /* add denied-path scenarios */ } main().catch(...)'
node --import tsx --eval 'async function main() { const { createCronTool } = await import("./src/agents/tools/cron-tool.ts"); const tool = createCronTool(); /* update denied-path scenarios */ } main().catch(...)'
node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts in the issue worktree: 1 file, 144 tests passed.
node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts in the review worktree: 1 file, 144 tests passed.
git diff --check in the issue worktree: passed.
GitHub statusCheckRollup for head 3c3dbf2c3a2e9285b86ccf32f8168fc55d0825a2: no failing or pending relevant checks; CI checks completed successfully/skipped/neutral.

Denied/fixed security path evidence:

mixed-case command payload add: DENIED_BEFORE_GATEWAY: cron command payloads cannot be created or edited through the agent cron tool; use the CLI or Gateway API.
mixed-case on-exit schedule add: DENIED_BEFORE_GATEWAY: cron on-exit schedules cannot be created or edited through the agent cron tool; use the CLI or Gateway API.
mixed-case command payload update: DENIED_BEFORE_GATEWAY: cron command payloads cannot be created or edited through the agent cron tool; use the CLI or Gateway API.
mixed-case on-exit schedule update: DENIED_BEFORE_GATEWAY: cron on-exit schedules cannot be created or edited through the agent cron tool; use the CLI or Gateway API.

Protected sink/source result:

Gateway tool calls: 0 for denied shell-backed add/update inputs in the focused regression tests.
Subprocess calls: zero; process not spawned; command runner not called for the denied agent cron tool inputs.
No cron.add or cron.update request is sent for those denied inputs, so the Gateway command execution sink is not reached.

Positive benign control:

Allowed normal agent-turn cron tool calls still succeed in the focused cron tool suite: existing tests for regular cron add/update paths expect the Gateway tool call to be invoked and still pass.
Intended behavior still works: reminder-style agentTurn cron jobs can still use the agent cron tool; only already-forbidden command/on-exit shell-backed jobs are blocked at the agent-tool policy boundary.

Compatibility/operator note: this changes only agent-tool behavior for already-forbidden command/on-exit cron jobs. It does not change cron schemas, persisted cron data, config/defaults, or the trusted CLI/Gateway command-cron path.

Live gaps: I inspected issue-appropriate package scripts and found cron Docker/integration lanes (test:docker:cron-cli, test:docker:cron-mcp-cleanup). They were not run because the remote proof backends available to this session are blocked before source sync: Testbox requires Crabbox newer than the installed 0.20.0 binary, and direct AWS Crabbox is not logged in on this host. No live provider, native client, browser, Telegram, or screenshot proof is required for this cron tool boundary.

pgondhi987 · 2026-07-07T05:07:58Z

@clawsweeper re-review

pgondhi987 · 2026-07-07T05:38:01Z

Verification before merge:

Behavior addressed: agent-facing cron tool calls can no longer bypass the shell-execution guard with mixed-case command/on-exit kinds.
Real environment tested: local PR checkout, GitHub Actions PR CI, ClawSweeper current-head proof/re-review; no Mantis Telegram proof was requested.
Exact head verified: 3c3dbf2c3a2e9285b86ccf32f8168fc55d0825a2.
Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/agents/tools/cron-tool.test.ts
node --import tsx --eval '<cron tool denied-path harness>'
git diff --check
timeout 1800 .agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main
GHSA dry-run gate and GHSA real gate via the deterministic orchestrator primitive
Evidence after fix:
Denied mixed-case command/on-exit add and update calls returned the cron tool policy denial before Gateway dispatch; Gateway tool calls/subprocess calls: zero.
Focused cron-tool Vitest passed: 1 file, 144 tests.
review-pr: passed, READY FOR /prepare-pr, no blocker/important findings.
autoreview: passed, no accepted/actionable findings.
ClawSweeper proof/re-review: proof sufficient for current head; remaining note is maintainer/stale-base merge decision, not a source fix.
CI: current-head check rollup had no pending or failing checks after the proof body update.
GHSA dry-run: passed. GHSA real gate: passed.
Observed result after fix: mixed-case shell-backed cron inputs fail at the agent cron tool boundary while normal agent-turn cron behavior remains covered by the passing cron-tool suite.
What was not tested: Testbox/AWS Crabbox proof was unavailable on this host because the installed Crabbox is 0.20.0 for Testbox and direct AWS Crabbox is not logged in; cron Docker lanes were inspected but not run.

Regression Risk:
Low. The affected boundary is the agent cron tool policy check before Gateway cron.add/cron.update; auth, sandbox, approvals, config, storage, provider/plugin/channel behavior, protocol schemas, and persisted cron data are unchanged. Trusted CLI/Gateway command cron support remains unchanged.

Best fix verdict: appropriate. The fix belongs at the agent tool guard because the Gateway/CLI command-cron path is intentionally trusted; moving the denial to Gateway would break that supported surface.

User behavior change:
Before, mixed-case Command or On-Exit values could pass through the agent cron tool and normalize into shell-backed cron jobs. After, those values are denied through add and update before Gateway dispatch; ordinary reminder-style agent cron jobs continue through the existing flow.

steipete · 2026-07-07T09:51:57Z

Land-ready verification for exact head efcdfa377123298cea8f4cf3c17cfad82775ecff:

Current-main symptom reproduced on sanitized AWS Crabbox: run_21427c843258 combined the new regression cases with the unpatched src/agents/tools/cron-tool.ts; both mixed-case Command add/update cases failed and reached the mocked Gateway.
The separate mixed-case on-exit claim was disproved on current main: run_beacbda457f9 passed both deny cases because canonicalizeCronToolObject already derives on-exit from schedule.command. I removed that redundant production/test delta.
Exact-head focused proof: provider aws, lease cbx_e4653c3a8908, run run_b62a042cc371; pnpm test src/agents/tools/cron-tool.test.ts passed 142/142 tests. The lease used public networking, no Tailscale, no instance role, no hydration, and was stopped after proof.
Structured autoreview on the exact branch diff was clean with confidence 0.91.
Exact-head hosted CI succeeded: https://github.com/openclaw/openclaw/actions/runs/28856592109
OPENCLAW_TESTBOX=1 scripts/pr prepare-run 101350 completed with gates_mode=hosted_exact_or_recent_rebase.

Best-fix verdict: this is the right boundary. src/agents/tools/cron-tool.ts owns the agent/MCP policy and must reject before src/cron/normalize.ts canonicalizes the payload; moving the restriction into shared cron normalization would break intentionally supported CLI/Gateway command jobs. No proof gaps remain for this two-line policy correction.

steipete · 2026-07-07T09:52:24Z

Merged via squash.

Prepared head SHA: efcdfa377123298cea8f4cf3c17cfad82775ecff
Landed commit: 9133d552ac19ebea40403f58a04415ea75053c25

…101350) * fix: normalize cron tool shell guard kinds * fix(cron): narrow mixed-case shell guard --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

fix: normalize cron tool shell guard kinds

3c3dbf2

openclaw-barnacle Bot added agents Agent runtime and tooling size: XS maintainer Maintainer-authored PR labels Jul 7, 2026

steipete self-assigned this Jul 7, 2026

fix(cron): narrow mixed-case shell guard

efcdfa3

steipete merged commit 9133d55 into openclaw:main Jul 7, 2026
107 checks passed

github-actions Bot mentioned this pull request Jul 7, 2026

📡 Upstream Digest — 2026-07-07 10:48 UTC curtismercier/openclaw-mods#1229

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix: block mixed-case cron shell jobs from agent tool [AI]#101350

fix: block mixed-case cron shell jobs from agent tool [AI]#101350
steipete merged 2 commits into
openclaw:mainfrom
pgondhi987:fix/fix-824

pgondhi987 commented Jul 7, 2026 •

edited by steipete

Loading

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

clawsweeper Bot commented Jul 7, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 7, 2026 •

edited

Loading

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

steipete commented Jul 7, 2026

Uh oh!

Uh oh!

steipete commented Jul 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

pgondhi987 commented Jul 7, 2026 • edited by steipete 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!

pgondhi987 commented Jul 7, 2026

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

pgondhi987 commented Jul 7, 2026

Uh oh!

steipete commented Jul 7, 2026

Uh oh!

Uh oh!

steipete commented Jul 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pgondhi987 commented Jul 7, 2026 •

edited by steipete

Loading

clawsweeper Bot commented Jul 7, 2026 •

edited

Loading

clawsweeper Bot commented Jul 7, 2026 •

edited

Loading