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

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

Best possible solution:

Land the xAI OAuth docs clarification after the exact code_execution error example and auth table are aligned with the supported runtime behavior.

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

Not applicable: this is a docs-only PR, not a reported runtime bug. The review compared the proposed docs text against current main's xAI auth and code_execution source contracts.

Is this the best way to solve the issue?

No: the overall docs direction is good, but the exact returned-error example should match current runtime or be paired with a runtime-message/test update.

Label changes:

• add P3: This is a low-risk docs clarification PR with a contained documentation accuracy issue.
• add rating: 🦐 gold shrimp: Current PR rating is 🦐 gold shrimp because proof is 🌊 off-meta tidepool, patch quality is 🦐 gold shrimp, and Useful docs update with focused validation, but one returned-output example and one auth table row need accuracy fixes before merge.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

Label justifications:

• P3: This is a low-risk docs clarification PR with a contained documentation accuracy issue.
• rating: 🦐 gold shrimp: Current PR rating is 🦐 gold shrimp because proof is 🌊 off-meta tidepool, patch quality is 🦐 gold shrimp, and Useful docs update with focused validation, but one returned-output example and one auth table row need accuracy fixes before merge.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

Full review comments:

• [P2] Keep the code_execution error example in sync — docs/tools/code-execution.md:146
  This JSON block now documents a message that the tool does not return: current main still emits the onboarding-command guidance in both extensions/xai/code-execution.ts and the lazy wrapper in extensions/xai/index.ts. Since the paragraph says this is the structured error returned without auth, users and support will see different guidance unless the runtime message is changed in the same PR or this example stays aligned with the actual output.
  Confidence: 0.9
• [P3] Keep API-key auth profiles in the Auth row — docs/tools/code-execution.md:16
  The table now narrows auth profiles to xAI OAuth auth profile, but this page also recommends openclaw models auth login --provider xai --method api-key, which stores an API-key auth profile that the runtime can resolve. Keeping the row as xAI auth profile avoids excluding a supported setup path.
  Confidence: 0.84

Overall correctness: patch is incorrect
Overall confidence: 0.88

Acceptance criteria:

• pnpm docs:list
• git diff --check
• node scripts/run-vitest.mjs extensions/xai/code-execution.test.ts extensions/xai/index.test.ts if runtime messages are changed

What I checked:

• Protected PR context: The GitHub context marks the PR author association as MEMBER and includes the protected maintainer label, so this workflow should not auto-close it. (3fdc2397e317)
• PR diff scope: The PR commit modifies four docs files with xAI OAuth and code_execution wording only. (3fdc2397e317)
• xAI auth choices exist: Current main declares xAI API-key, OAuth, and device-code provider auth choices, matching the PR's main setup direction. (extensions/xai/openclaw.plugin.json:40, ecb6da9289b1)
• code_execution auth behavior: Current main enables code_execution when xAI credentials are resolvable and explicitly supports auth profiles, env vars, or plugin config fallback. (extensions/xai/src/tool-auth-shared.ts:185, ecb6da9289b1)
• Runtime error message mismatch: The runtime code still returns onboarding-command guidance for missing code_execution credentials, while the PR's docs example says the returned JSON uses openclaw models auth login commands. (extensions/xai/code-execution.ts:109, ecb6da9289b1)
• PR docs example line: The PR changes the documented missing_xai_api_key JSON message to text that does not match current main's returned message. Public docs: docs/tools/code-execution.md. (docs/tools/code-execution.md:146, 3fdc2397e317)

Likely related people:

• FullerStackDev: Commit 896fd13 added the xAI device-code OAuth flow and updated docs/providers/xai.md, which is the central behavior this docs PR clarifies. (role: introduced recent xAI OAuth/device-code behavior; confidence: high; commits: 896fd13b1c61; files: extensions/xai/xai-oauth.ts, extensions/xai/openclaw.plugin.json, docs/providers/xai.md)
• Ayaan Zaidi: Recent commits on extensions/xai adjusted the public plugin test runtime and device-code discovery after the OAuth work landed. (role: recent area contributor; confidence: medium; commits: 1d77170a305b, b66e91ba77e3; files: extensions/xai)
• clawsweeper[bot]: Current blame for the xAI plugin and code_execution docs points to the squash commit that introduced the large xAI plugin/docs surface on main. (role: original xAI plugin/docs carrier in current history; confidence: medium; commits: cbaf85822798; files: extensions/xai/code-execution.ts, extensions/xai/index.ts, docs/tools/code-execution.md)

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

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchable usually means sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.