• 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 policy, generated mirror, baseline, and regression tests once a maintainer explicitly accepts the trusted-parent-env boundary and the override hardening compatibility impact.

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

Yes, at source level: current main derives XDG_CONFIG_HOME and XDG_CONFIG_DIRS into blockedInheritedKeys, and the host exec path passes process.env through that sanitizer before spawning subprocesses. The PR body also reports a live AWS Crabbox agent exec proof showing the XDG values after the patch.

Is this the best way to solve the issue?

Yes, with maintainer approval: the PR changes the shared policy buckets instead of adding a bypass, keeps request overrides blocked, regenerates the macOS mirror, and adds focused regression coverage. The remaining question is policy ownership of the compatibility/security boundary, not a code-shape defect.

Label changes:

• add P1: The PR fixes a deterministic host exec bug that can break persisted tool config and OAuth state for real containerized deployments.
• add merge-risk: 🚨 compatibility: The diff rejects additional request-scoped XDG overrides, which can intentionally break existing per-call env override workflows after upgrade.
• add merge-risk: 🚨 security-boundary: The diff changes which host exec environment variables are trusted from inherited process state versus rejected from untrusted request overrides.
• add proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix live AWS Crabbox proof of a real openclaw agent --local exec subprocess receiving inherited XDG values, with the passing assertion and run id recorded.
• add rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🦞 diamond lobster, patch quality is 🐚 platinum hermit, and Small focused patch with strong live proof, capped by a host exec security and compatibility boundary that needs maintainer approval.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body includes after-fix live AWS Crabbox proof of a real openclaw agent --local exec subprocess receiving inherited XDG values, with the passing assertion and run id recorded.

Label justifications:

• P1: The PR fixes a deterministic host exec bug that can break persisted tool config and OAuth state for real containerized deployments.
• merge-risk: 🚨 compatibility: The diff rejects additional request-scoped XDG overrides, which can intentionally break existing per-call env override workflows after upgrade.
• merge-risk: 🚨 security-boundary: The diff changes which host exec environment variables are trusted from inherited process state versus rejected from untrusted request overrides.
• rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🦞 diamond lobster, patch quality is 🐚 platinum hermit, and Small focused patch with strong live proof, capped by a host exec security and compatibility boundary that needs maintainer approval.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body includes after-fix live AWS Crabbox proof of a real openclaw agent --local exec subprocess receiving inherited XDG values, with the passing assertion and run id recorded.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix live AWS Crabbox proof of a real openclaw agent --local exec subprocess receiving inherited XDG values, with the passing assertion and run id recorded.

Security concerns:

• [medium] Confirm the trusted inherited XDG boundary — src/infra/host-env-security-policy.json:272
  Allowing inherited XDG roots is likely the right operator-owned boundary, but it lets the parent OpenClaw process environment steer subprocess config/data paths while rejecting per-call overrides; a maintainer should explicitly approve that trust split before merge.
  Confidence: 0.86

What I checked:

• working tree clean: The review started from a clean current-main checkout at 7f49964. (7f499643b232)
• current-main policy strips inherited XDG config vars: Current main lists XDG_CONFIG_HOME and XDG_CONFIG_DIRS in blockedOverrideOnlyKeys but not in allowedInheritedOverrideOnlyKeys, so the derivation treats them as inherited-blocked. (src/infra/host-env-security-policy.json:195, 7f499643b232)
• current-main derivation explains the bug: derivePolicyArrays builds blockedInheritedKeys from blocked-everywhere keys plus override-only keys that are not inherited-allowed. (src/infra/host-env-security-policy.js:23, 7f499643b232)
• current-main exec call path uses the sanitizer: The gateway exec path passes process.env as baseEnv and request params.env as overrides into sanitizeHostExecEnvWithDiagnostics, so policy buckets directly control subprocess inheritance and override rejection. (src/agents/bash-tools.exec.ts:1452, 7f499643b232)
• PR policy change separates inheritance from overrides: The PR adds all XDG base-directory variables to the override block bucket and to allowedInheritedOverrideOnlyKeys, removing XDG_CONFIG_HOME and XDG_CONFIG_DIRS from derived inherited-blocked output while keeping request overrides blocked. (src/infra/host-env-security-policy.json:192, 599640f141a1)
• PR tests cover both sides of the boundary: The sanitizer tests add inherited XDG expectations and override rejection coverage for XDG cache, config, data, runtime, and state variables; baseline and Swift parity artifacts are updated too. (src/infra/host-env-security.test.ts:548, 599640f141a1)

Likely related people:

• joshavant: Commit 7abfff7 added host env override enforcement and added XDG_CONFIG_HOME to the affected policy path; this PR author also has prior merged history on the same sanitizer boundary. (role: introduced relevant override hardening; confidence: high; commits: 7abfff756d6c; files: src/infra/host-env-security-policy.json, src/infra/host-env-security.ts, src/agents/bash-tools.exec.path.test.ts)
• pgondhi987: Commit 2d126fc added allowedInheritedOverrideOnlyKeys, derived blockedInheritedKeys, and reported-baseline enforcement on the affected host env security policy path. (role: introduced inherited-policy derivation; confidence: high; commits: 2d126fc62343; files: src/infra/host-env-security-policy.js, src/infra/host-env-security-policy.json, src/infra/host-env-security.reported-baseline.test.ts)
• eleqtrizit: Commit fa82193 introduced the separate policy module and aligned inherited host exec environment filtering, so this history is directly adjacent to the current PR's boundary. (role: adjacent inherited-env policy contributor; confidence: medium; commits: fa82193c7273; files: src/infra/host-env-security-policy.js, src/infra/host-env-security-policy.json, src/infra/host-env-security.ts)

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

• 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.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• 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.