fix: Tailscale serve + auth.mode=none exposes gateway to full... by coygeek · Pull Request #50631 · openclaw/openclaw

coygeek · 2026-03-19T20:47:02Z

Fix Summary

When gateway.auth.mode is set to "none" and gateway.tailscale.mode is set to "serve", the gateway is reachable over the user's entire Tailnet with zero authentication. Any Tailnet peer connecting through the Tailscale serve URL receives { ok: true, method: "none" } from authorizeGatewayConnect without presenting any credential, gaining full operator-level access to the gateway control plane.

Issue Linkage

Fixes #50630

Security Snapshot

CVSS v3.1: 9.3 (Critical)
CVSS v4.0: 9.3 (Critical)

Implementation Details

Files Changed

src/gateway/server-runtime-config.test.ts (+49/-0)
src/gateway/server-runtime-config.ts (+5/-0)

Technical Analysis

The startup validation chain in resolveGatewayRuntimeConfig has three relevant guards:

assertGatewayAuthConfigured (auth.ts:285) — validates token/password/trusted-proxy preconditions but has no branch for mode === "none". Passes silently for any tailscale configuration.
The funnel guard (server-runtime-config.ts:125) — blocks authMode !== "password" when tailscaleMode === "funnel". Does not apply to tailscaleMode === "serve".
The non-loopback LAN guard (server-runtime-config.ts:133) — blocks mode: "none" on LAN/custom binds by requiring hasSharedSecret || authMode === "trusted-proxy". Does not apply here because Tailscale serve enforces loopback bind (server-runtime-config.ts:130), so isLoopbackHost(bindHost) is true.

The combination tailscaleMode === "serve" + authMode === "none" satisfies all three guards:

Guard at line 130 passes because serve mode enforces loopback — which then exempts the connection from the non-loopback guard at line 133.
The funnel-only guard at line 125 does not apply to serve.
assertGatewayAuthConfigured passes silently for mode: "none".

resolveGatewayRuntimeConfig succeeds, the gateway starts, and authorizeGatewayConnect unconditionally returns { ok: true, method: "none" } (auth.ts:402-404) for every incoming connection. Tailscale's local proxy relays requests from any Tailnet peer to the loopback gateway port, bypassing the auth check entirely.

Additionally, resolveGatewayAuth at auth.ts:271-273 auto-enables allowTailscale when tailscaleMode === "serve" and mode !== "password" && mode !== "trusted-proxy" — this sets allowTailscale: true for mode: "none" + serve, though the mode: "none" early return in authorizeGatewayConnect fires before the Tailscale header auth path is reached.

Deterministic repro config:

gateway:
  auth:
    mode: none
  tailscale:
    mode: serve

Steps:

Set gateway.auth.mode = "none" and gateway.tailscale.mode = "serve" in ~/.openclaw/openclaw.json.
Start the gateway: openclaw gateway run.
From any other device on the same Tailnet, connect to the Tailscale serve URL (e.g., https://<hostname>.ts.net).
Observe: connection is accepted with authMethod: "none" — no token, password, or device pairing required.

Validation Evidence

Command: pnpm exec oxlint src/ && pnpm build && pnpm check && pnpm test
Status: passed

Risk and Compatibility

non-breaking; no known regression impact

AI-Assisted Disclosure

AI-assisted: yes
Model: opencode/claude-sonnet-4-6

…tive Co-authored-by: Claude <noreply@anthropic.com>

greptile-apps · 2026-03-19T20:48:57Z

Greptile Summary

This PR fixes a critical security vulnerability (CVSS 9.3) where combining gateway.auth.mode=none with gateway.tailscale.mode=serve allowed any Tailnet peer to reach the gateway control plane with zero authentication. The root cause was that three existing guards each had a blind spot: the funnel-only guard (line 125) didn't apply to serve, the non-loopback guard (line 138) was exempted because Tailscale serve forces a loopback bind, and assertGatewayAuthConfigured has no branch for mode=none.

The fix adds a minimal, targeted startup-time guard at server-runtime-config.ts:130–134 that throws when tailscaleMode === "serve" && authMode === "none", preventing the gateway from starting in the misconfigured state entirely. Test coverage is solid: the new rejection case, the adjacent funnel+none case (which hits the pre-existing funnel guard, acting as a regression anchor if guard order ever changes), and a positive serve+token case are all included.

Confidence Score: 5/5

This PR is safe to merge — it adds a narrow, well-tested startup guard with no breaking changes to existing valid configurations.
The fix is minimal (5 lines of guard + 49 lines of tests), correctly targets the only unguarded combination (serve + none), and doesn't touch the happy paths for any other auth/tailscale mode combination. Test coverage directly exercises the new guard, the adjacent funnel guard, and a positive path. The prior thread concern about the guard being dead code for the funnel path is accurate but non-blocking — it's a no-harm condition since the funnel guard is strictly stronger. No regression risk.
No files require special attention.

_{Reviews (2): Last reviewed commit: "fix(gateway): narrow serve+none guard to..." | Re-trigger Greptile}

greptile-apps · 2026-03-19T20:49:00Z

+  if (tailscaleMode !== "off" && authMode === "none") {
+    throw new Error(
+      "tailscale serve/funnel requires gateway auth — refusing to start with auth.mode=none when tailscale is active",
+    );
+  }


New guard is dead code for the funnel path

The new guard at line 130–134 is never reached when tailscaleMode === "funnel" + authMode === "none" because the preceding funnel guard at line 125 (tailscaleMode === "funnel" && authMode !== "password") already throws first. In practice this guard only fires for serve + none, even though the error message says "serve/funnel".

This isn't a bug — the existing funnel guard is strictly stronger (it rejects any non-password auth for funnel, not just none) — but the error message "tailscale serve/funnel requires gateway auth..." can be slightly misleading since a user with funnel + none will never see it. Consider narrowing the condition to tailscaleMode === "serve" to match what the guard actually covers:

Suggested change

if (tailscaleMode !== "off" && authMode === "none") {

throw new Error(

"tailscale serve/funnel requires gateway auth — refusing to start with auth.mode=none when tailscale is active",

);

}

if (tailscaleMode === "serve" && authMode === "none") {

throw new Error(

"tailscale serve requires gateway auth — refusing to start with auth.mode=none when tailscale serve is active",

);

}

Alternatively, keep the broader condition but reorder: place this guard before the funnel guard so it acts as the first line of defence for both modes and the funnel guard then enforces the additional password requirement. Either way, the currently-passing "rejects tailscale funnel with auth.mode=none" test inadvertently verifies the older guard rather than the new one.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/gateway/server-runtime-config.ts Line: 130-134 Comment: **New guard is dead code for the funnel path** The new guard at line 130–134 is never reached when `tailscaleMode === "funnel"` + `authMode === "none"` because the preceding funnel guard at line 125 (`tailscaleMode === "funnel" && authMode !== "password"`) already throws first. In practice this guard only fires for `serve + none`, even though the error message says "serve/funnel". This isn't a bug — the existing funnel guard is strictly stronger (it rejects any non-password auth for funnel, not just `none`) — but the error message `"tailscale serve/funnel requires gateway auth..."` can be slightly misleading since a user with `funnel + none` will never see it. Consider narrowing the condition to `tailscaleMode === "serve"` to match what the guard actually covers: ```suggestion if (tailscaleMode === "serve" && authMode === "none") { throw new Error( "tailscale serve requires gateway auth — refusing to start with auth.mode=none when tailscale serve is active", ); } ``` Alternatively, keep the broader condition but reorder: place this guard *before* the funnel guard so it acts as the first line of defence for both modes and the funnel guard then enforces the additional password requirement. Either way, the currently-passing `"rejects tailscale funnel with auth.mode=none"` test inadvertently verifies the older guard rather than the new one. How can I resolve this? If you propose a fix, please make it concise.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 33f58e5957

ℹ️ 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-03-19T20:52:40Z

+  if (tailscaleMode !== "off" && authMode === "none") {
+    throw new Error(
+      "tailscale serve/funnel requires gateway auth — refusing to start with auth.mode=none when tailscale is active",


Reject this serve+none combo before install flows consume it

When an existing config has gateway.auth.mode: "none" with gateway.tailscale.mode: "serve", this new runtime-only throw will make the installed daemon fail on first boot, but the setup/install path still treats that config as valid. resolveGatewayAuth() still sets allowTailscale=true for serve+none (src/gateway/auth.ts:271-273), and resolveGatewayInstallToken() uses that to skip generating or persisting a token (src/commands/gateway-install-token.ts:60-66) before openclaw gateway install writes the service. The install appears to succeed, then the service immediately dies when it reaches this branch, so this combination needs to be rejected or normalized before install/validation rather than only here at startup.

Useful? React with 👍 / 👎.

The new auth.mode=none guard was dead code for the funnel path because the preceding funnel guard (line 125) already rejects funnel+non-password. Narrow the condition from tailscaleMode !== "off" to tailscaleMode === "serve" so the guard matches only the configuration it actually covers, and update the error message and test assertion accordingly. Addresses Greptile review feedback on PR openclaw#50631.

coygeek · 2026-03-24T03:09:44Z

@greptile-apps revuew

clawsweeper · 2026-04-28T12:02:03Z

Codex review: needs real behavior proof before merge.

Latest ClawSweeper review: 2026-05-22 10:44 UTC / May 22, 2026, 6:44 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
The branch adds a runtime-config rejection and tests for gateway.auth.mode="none" with gateway.tailscale.mode="serve", while preserving Serve with token auth and the existing Funnel rejection.

Reproducibility: yes. at source level. Current main accepts gateway.auth.mode="none" with gateway.tailscale.mode="serve", has a test asserting that shape succeeds, and then authorizes mode none before Tailscale identity or shared-secret checks run.

PR rating
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
Summary: The patch targets the right runtime gap, but missing real behavior proof, the preflight validation gap, and a conflicting head make it not quality-ready for merge.

Rank-up moves:

Add shared install/onboarding preflight validation for Serve plus explicit no-auth.
Add redacted real Tailscale Serve after-fix proof to the PR body so ClawSweeper can re-review.
Rebase or replace the conflicting branch before merge.

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.

Real behavior proof
Needs real behavior proof before merge: The PR body lists tests/checks only; it still needs redacted after-fix Tailscale Serve terminal output, logs, a recording, or a linked artifact before merge. 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

No after-fix real Tailscale Serve proof is present; the PR body lists tests/checks only.
The runtime-only guard can let install/onboarding accept a daemon plan that later fails when the gateway process starts.
Merging intentionally makes existing explicit gateway.auth.mode: "none" plus tailscale.mode: "serve" setups fail closed, so upgrade messaging and maintainer ownership matter.
The PR head is currently conflicting with main, so any accepted path needs a rebase or replacement before merge.

Maintainer options:

Complete shared preflight before merge (recommended)
Add Serve plus explicit no-auth rejection before install/onboarding service plans are accepted, keep the runtime guard, and require redacted real Tailscale proof for the final behavior.
Accept runtime-only fail-closed behavior
Maintainers could intentionally merge the startup guard alone, but they would own the install-success-then-daemon-fails path and missing real-environment proof.
Replace the stale conflicting branch
If repairing this PR is not worth the proof and conflict churn, close it after opening or landing a narrow replacement that covers runtime and preflight together.

Next step before merge
Human review is needed because this security-boundary PR needs shared preflight coverage, contributor-supplied real Tailscale proof, and conflict resolution before merge.

Security
Needs attention: No supply-chain changes were found, but this auth-boundary fix remains incomplete until Serve plus explicit no-auth is rejected in preflight as well as runtime startup.

Review findings

[P2] Reject serve+none before install flows consume it — src/gateway/server-runtime-config.ts:132-136

Review details

Best possible solution:

Centralize shared validation that rejects explicit no-auth with Tailscale Serve in runtime and install/onboarding preflight, preserve loopback-only no-auth, update focused tests/docs, and require redacted live proof before merge.

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

Yes, at source level. Current main accepts gateway.auth.mode="none" with gateway.tailscale.mode="serve", has a test asserting that shape succeeds, and then authorizes mode none before Tailscale identity or shared-secret checks run.

Is this the best way to solve the issue?

No, not as written. The runtime guard is the right direction, but the maintainable fix should also reject this configuration before install/onboarding writes or accepts it.

Label justifications:

P0: The PR addresses a concrete Gateway authentication-bypass path that can expose operator-level access to Tailnet peers without credentials.
merge-risk: 🚨 compatibility: The change intentionally makes existing Serve plus explicit no-auth configurations fail closed instead of continuing to start.
merge-risk: 🚨 security-boundary: The diff changes the Gateway authentication boundary for Tailscale Serve but does not enforce the policy in shared preflight paths.
merge-risk: 🚨 availability: As written, setup paths can still accept the dangerous config and produce a service that fails only at daemon startup.
rating: 🧂 unranked krab: Current PR rating is 🧂 unranked krab because proof is 🧂 unranked krab, patch quality is 🦐 gold shrimp, and The patch targets the right runtime gap, but missing real behavior proof, the preflight validation gap, and a conflicting head make it not quality-ready for merge.
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 tests/checks only; it still needs redacted after-fix Tailscale Serve terminal output, logs, a recording, or a linked artifact before merge. 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.

Full review comments:

[P2] Reject serve+none before install flows consume it — src/gateway/server-runtime-config.ts:132-136
This throw only runs after the gateway process starts. Install and onboarding paths can accept explicit no-auth before building service plans, so this config can appear to install successfully and then fail at daemon startup; add shared preflight validation before service plans are written.
Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.9

Security concerns:

[medium] Complete Serve/no-auth preflight validation — src/gateway/server-runtime-config.ts:132
Runtime-only rejection leaves setup and install paths treating the dangerous configuration as acceptable until the daemon starts, so the auth-boundary policy should be enforced before managed service plans are written.
Confidence: 0.88

What I checked:

Current main runtime gap: Current main validates configured auth, rejects non-password auth only for Funnel, enforces loopback for Tailscale modes, and has no Serve plus mode-none rejection. (src/gateway/server-runtime-config.ts:131, ff79299d68e3)
Mode none bypasses auth checks: authorizeGatewayConnectCore returns { ok: true, method: "none" } before Tailscale identity-header verification, token auth, or password auth can run. (src/gateway/auth.ts:504, ff79299d68e3)
Current test still accepts reported config: The runtime-config test configures explicit no-auth with Tailscale Serve and asserts successful loopback binding instead of startup rejection. (src/gateway/server-runtime-config.test.ts:311, ff79299d68e3)
Install preflight gap: Explicit gateway.auth.mode: "none" makes install token policy return false for requiring a token, and openclaw gateway install consumes that result before building the service plan. (src/gateway/auth-install-policy.ts:14, ff79299d68e3)
PR diff scope: The PR adds only a resolveGatewayRuntimeConfig startup throw plus focused tests, so setup/onboarding preflight paths remain outside the patch. (src/gateway/server-runtime-config.ts:132, 6bd6ea52f8dc)
Live PR state: GitHub reports this PR as open, conflicting, and closing the still-open companion issue [Bug]: Tailscale serve + auth.mode=none exposes gateway to full Tailnet without authentication #50630; the PR body lists tests/checks but no after-fix real Tailscale proof. (6bd6ea52f8dc)

Likely related people:

steipete: Recent path history shows repeated work on runtime config, auth hardening, and install-token/config write paths adjacent to this boundary. (role: recent gateway auth/runtime contributor; confidence: high; commits: 330ba1fa3194, 84dd9c73953b, 2fe39ce94957; files: src/gateway/server-runtime-config.ts, src/gateway/auth.ts, src/commands/gateway-install-token.ts)
vincentkoc: Recent path history links this person to startup config imports, legacy env handling, and trusted-proxy hardening near the same auth/runtime surface. (role: recent gateway auth/runtime contributor; confidence: high; commits: aa1834a3ff56, 1497425b8dbb, 1738d540f440; files: src/gateway/server-runtime-config.ts, src/gateway/auth.ts, src/gateway/auth-resolve.ts)
gumadeiras: The merged gateway auth bootstrap security PR restored explicit gateway.auth.mode: "none" support and touched the auth/runtime files involved here. (role: introduced adjacent mode-none behavior; confidence: medium; commits: c5698caca31d; files: src/gateway/auth.ts, src/gateway/server-runtime-config.ts, src/gateway/startup-auth.ts)
roshanasingh4: Merged Tailscale Serve header-auth work changed the gateway auth path and trust model adjacent to this PR. (role: adjacent Tailscale auth contributor; confidence: medium; commits: 8a9096cd52fd; files: src/gateway/auth.ts, src/gateway/auth.test.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against ff79299d68e3.

clawsweeper · 2026-05-19T23:02:59Z

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?

The egg game starts only after the PR passes the real-behavior proof check.
Before that, no creature or rarity is rolled. The treat waits for real proof.
This is still just collectible flavor: proof affects review readiness, not creature quality.

Fixes #50630. Replaces stale PR #50631. Behavior: reject gateway auth mode none when Tailscale Serve or Funnel exposes the gateway, across config validation, install-token preflight, and runtime startup. Proof: - node scripts/run-vitest.mjs src/config/config.gateway-tailscale-bind.test.ts src/gateway/server-runtime-config.test.ts src/commands/doctor-gateway-auth-token.test.ts - .agents/skills/autoreview/scripts/autoreview --mode local - node scripts/crabbox-wrapper.mjs run --shell -- "pnpm check:changed" (run_5a999c1e11c0, exit 0) - GitHub PR checks clean on 0b306e8; prior checkout/diff failures were GitHub infrastructure and cleared after rebase.

steipete · 2026-05-27T13:12:16Z

Closing because the fix landed through #87286 as dc5954b.

The landed patch keeps the same security intent and applies it at the shared policy/config/preflight/runtime surfaces, with mode-specific messaging for Funnel. Thanks @coygeek for the original report and patch direction.

Fixes openclaw#50630. Replaces stale PR openclaw#50631. Behavior: reject gateway auth mode none when Tailscale Serve or Funnel exposes the gateway, across config validation, install-token preflight, and runtime startup. Proof: - node scripts/run-vitest.mjs src/config/config.gateway-tailscale-bind.test.ts src/gateway/server-runtime-config.test.ts src/commands/doctor-gateway-auth-token.test.ts - .agents/skills/autoreview/scripts/autoreview --mode local - node scripts/crabbox-wrapper.mjs run --shell -- "pnpm check:changed" (run_5a999c1e11c0, exit 0) - GitHub PR checks clean on 0b306e8; prior checkout/diff failures were GitHub infrastructure and cleared after rebase.

fix(gateway): reject auth.mode=none when tailscale serve/funnel is ac…

33f58e5

…tive Co-authored-by: Claude <noreply@anthropic.com>

greptile-apps Bot reviewed Mar 19, 2026

View reviewed changes

openclaw-barnacle Bot added gateway Gateway runtime size: S labels Mar 19, 2026

chatgpt-codex-connector Bot reviewed Mar 19, 2026

View reviewed changes

This was referenced Apr 26, 2026

fix(gateway): block mode=none auth with tailscale serve remote exposure #51339

Closed

fix(gateway): default gateway.auth.mode to 'none' for local deployments #65333

Closed

RenzoMXD mentioned this pull request Apr 28, 2026

fix(gateway): preserve external Tailscale Funnel routes in serve mode #73755

Merged

6 tasks

This was referenced Apr 29, 2026

[Bug]: Tailscale serve + auth.mode=none exposes gateway to full Tailnet without authentication #50630

Closed

Tailscale serve mode lacks optional secondary authentication #57110

Open

clawsweeper Bot added the rating: 🌊 off-meta tidepool PR readiness rating does not apply to this item. label May 18, 2026

openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 18, 2026

steipete self-assigned this May 27, 2026

steipete mentioned this pull request May 27, 2026

fix(gateway): reject no-auth tailscale exposure #87286

Merged

steipete closed this May 27, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: Tailscale serve + auth.mode=none exposes gateway to full...#50631

fix: Tailscale serve + auth.mode=none exposes gateway to full...#50631
coygeek wants to merge 2 commits into
openclaw:mainfrom
coygeek:codex/aa-hso-tailscale-serve-with-auth-mode-none-bypasses-gateway-auth

coygeek commented Mar 19, 2026

Uh oh!

greptile-apps Bot commented Mar 19, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot Mar 19, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Mar 19, 2026

Uh oh!

coygeek commented Mar 24, 2026

Uh oh!

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 19, 2026 •

edited

Loading

Uh oh!

steipete commented May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

coygeek commented Mar 19, 2026

Fix Summary

Issue Linkage

Security Snapshot

Implementation Details

Files Changed

Technical Analysis

Validation Evidence

Risk and Compatibility

AI-Assisted Disclosure

Uh oh!

greptile-apps Bot commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Uh oh!

greptile-apps Bot Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

coygeek commented Mar 24, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

steipete commented May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

greptile-apps Bot commented Mar 19, 2026 •

edited

Loading

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading

clawsweeper Bot commented May 19, 2026 •

edited

Loading