Upgrade rejects unavailable optional Doctor check repeated on stderr

[shakkernerd]

Problem

OCM upgrades can roll back a healthy candidate when native Doctor does not register the optional codex/managed-app-server check.
A valid configuration with plugins.enabled=false triggers this case, and native discovery may also omit the check under its normal plugin-selection rules.

Evidence and cause

The failure reproduced with OpenClaw 2026.9.6 during a packaged-runtime upgrade, before service changes.
Doctor returned a nonzero exit with a single core/doctor/lint-selection error stating Unknown health check id selected by --only: codex/managed-app-server., checksRun: 0, and no other findings.
During an update, native Doctor also repeats that finding on stderr:

Doctor lint error [core/doctor/lint-selection]: Unknown health check id selected by --only: codex/managed-app-server.

On OCM main at 57bfe7c, candidate_codex_preflight_json_is_unsupported already recognizes the sole unknown-check result as a compatibility exception, but requires empty stderr.
The duplicate native diagnostic therefore prevents the exception and OCM restores the previous runtime.

Expected behavior

The existing compatibility exception should accept an exact stderr repetition of the same sole selection finding.
Native Doctor must continue to own plugin availability and check selection.
Supported checks must still run, and mixed findings, malformed results, and additional stderr errors must still stop the upgrade.
The strict failure protections established by #128 should remain intact.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 26, 2026, 1:10 AM ET / 05:10 UTC.

Summary
Current main still rejects the reported sole Doctor finding when Doctor repeats it on stderr. An open, same-author PR explicitly targets this issue, so the issue remains open while that fix is reviewed. The earlier mixed-failure safeguard remains part of the expected behavior.

Reproducibility: yes. from current source: the reported sole JSON finding plus its repeated stderr line fails the empty-stderr guard, and the caller rejects the candidate. This read-only review did not execute an upgrade.

Regression provenance
Possible regression — probable (reviewed change; failure trace). No predecessor PR is attributed.

Root-cause cluster
Relationship: canonical
Canonical: #263
Summary: The open pull request is the candidate fix for this issue; the earlier closed report addressed the opposite, overly permissive result classification.

Members:

• fixed_by_candidate: fix: allow unavailable Doctor checks repeated on stderr #268 - It explicitly closes this issue and targets the repeated-stderr case.
• adjacent_distinct: Candidate preflight treats mixed unsupported-check failures as success #128 - It concerned accepting mixed failures and was closed after the stricter classifier landed.
• adjacent_distinct: fix: reject mixed candidate preflight failures #165 - Its merged safety change established the strict result classification that the current fix must preserve.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
Open PR #268 explicitly owns the fix; review its pending packaged-runtime proof before landing rather than dispatching a parallel repair.

Review details

Best possible solution:

Keep native Doctor responsible for check discovery, and accept only its exact stderr echo of the sole structured selection finding while preserving rejection of mixed or additional errors.

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

Yes, from current source: the reported sole JSON finding plus its repeated stderr line fails the empty-stderr guard, and the caller rejects the candidate. This read-only review did not execute an upgrade.

Is this the best way to solve the issue?

Yes, the existing result classifier is the narrow repair boundary. The linked PR should retain the documented sole-failure rule and prove both the accepted duplicate and rejected mixed-error cases.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P2: A specific optional-check response blocks an otherwise healthy packaged-runtime upgrade on current main.
• add impact:other: The impact is an unnecessary upgrade rejection and runtime restoration, outside the more specific owned impact classes.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P2: A specific optional-check response blocks an otherwise healthy packaged-runtime upgrade on current main.
• impact:other: The impact is an unnecessary upgrade rejection and runtime restoration, outside the more specific owned impact classes.

Evidence reviewed

What I checked:

• Reviewed revision: The clean checkout is current main at the issue’s cited revision. (57bfe7c23b13)
• Native Doctor boundary: OCM invokes the staged runtime’s doctor --lint --only codex/managed-app-server --json; the staged OpenClaw runtime supplies the check selection and output. (src/cli/upgrade.rs:506, 57bfe7c23b13)
• Failure reaches upgrade rejection: A nonzero Doctor exit continues only if the unsupported-result classifier accepts it; otherwise OCM returns a candidate failure. (src/cli/upgrade.rs:3905, 57bfe7c23b13)
• Current defect: The structured-result classifier rejects every nonempty stderr before checking whether the JSON contains the sole expected selection finding. The reported exact stderr repetition therefore fails on current main. (src/cli/upgrade.rs:5981, 57bfe7c23b13)
• Existing contract and controls: The usage guide permits only a sole unsupported-check failure; current unit controls reject mixed findings and unrelated stderr but do not accept the exact duplicate native diagnostic. (docs/USAGE.md:511, 57bfe7c23b13)
• Upgrade regression boundary: Isolated CLI fixtures establish that a passing check precedes finalization and a mixed unsupported result keeps the old runtime binding. (tests/upgrade_command_tests.rs:7146, 57bfe7c23b13)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)
• fuller-stack-dev: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• shakkernerd: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.