fix: use macOS product version in runtime prompts#95194
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close as superseded: this draft is a plausible fix for the macOS Tahoe runtime prompt bug, but the same remaining work is already owned by a proof-positive sibling PR while this branch still has only mocked proof. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Keep the remaining work on #95189, land one cached helper covering all three runtime prompt producers, then close overlapping PRs and the linked issue after it reaches main. So I’m closing this here and keeping the remaining discussion on #95189. Review detailsBest possible solution: Keep the remaining work on #95189, land one cached helper covering all three runtime prompt producers, then close overlapping PRs and the linked issue after it reaches main. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection shows current main and v2026.6.9 still use Is this the best way to solve the issue? No. This branch is plausible, but the best remaining path is the proof-positive sibling at #95189 because it covers the same runtime prompt producers with live macOS proof and stronger cache/test coverage. Security review: Security review cleared: No concrete security or supply-chain concern was found; the diff changes local TypeScript OS metadata helpers and tests only. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against d1cbe29f3d52. |
771033a to
557a06b
Compare
557a06b to
b2f2220
Compare
Summary
Fixes #95145.
OpenClaw already used
sw_vers -productVersionfor status/presence OS summaries, but agent runtime prompt metadata still usedos.type()plusos.release(). On macOS Tahoe that exposes Darwin25.xinstead of macOS26.x.This PR adds a shared runtime OS-name helper in
src/infra/os-summary.tsand uses it in:src/agents/embedded-agent-runner/run/attempt.tssrc/agents/embedded-agent-runner/compact.tssrc/agents/cli-runner/helpers.tsThe helper intentionally returns OS name/release without architecture so
buildRuntimeLine()can continue appending the existing separatearchfield.Review feedback addressed
${os.type()} ${os.release()}outside Darwin.resolveOsSummary()label behavior unchanged for Linux/Windows.Verification
node scripts/run-vitest.mjs src/infra/os-summary.test.tsnode scripts/run-vitest.mjs src/agents/cli-runner/helpers.system-prompt.test.tsnode scripts/run-vitest.mjs src/agents/embedded-agent-runner/run/attempt-system-prompt.test.tsgit diff --check origin/main...HEADAutoreview attempted with
python .agents\skills\autoreview\scripts\autoreview --mode branch --base origin/main, but this Windows environment still fails to spawn the Codex reviewer executable withPermissionError: [WinError 5] Access is deniedfrom the WindowsApps Codex path.Real behavior proof
Behavior addressed: macOS Tahoe runtime prompt metadata no longer exposes the Darwin kernel release as the OS version.
Real environment tested: Windows checkout with mocked Darwin
25.5.0and mockedsw_versoutput26.5.1in focused unit tests.Exact steps or command run after this patch:
node scripts/run-vitest.mjs src/infra/os-summary.test.ts;node scripts/run-vitest.mjs src/agents/cli-runner/helpers.system-prompt.test.ts;node scripts/run-vitest.mjs src/agents/embedded-agent-runner/run/attempt-system-prompt.test.ts;git diff --check origin/main...HEAD.Evidence after fix:
resolveOsRuntimeName()returnsmacos 26.5.1for Darwin25.5.0whensw_versreports26.5.1, CLI prompt metadata includesos=macos 26.5.1, and Linux/Windows runtime names preserve the previousos.type()shape (Linux ...,Windows_NT ...).Observed result after fix: all three focused Vitest files passed after rebasing on latest
origin/main.What was not tested: no live macOS 26/Tahoe host was available in this environment, so live Tahoe Runtime-line proof is still missing.