Description

Two tests in src/config/config.nix-integration-u3-u5-u9.test.ts consistently fail on the Windows CI runner (checks-windows). The failures are not caused by any specific PR — they reproduce on every branch that triggers the Windows test job.

Failing tests

1. "STATE_DIR respects OPENCLAW_HOME when state override is unset"
2. "CONFIG_PATH defaults to OPENCLAW_HOME/.openclaw/openclaw.json"

Error

AssertionError: expected '\custom\home\.openclaw' to be 'C:\custom\home\.openclaw'
AssertionError: expected '\custom\home\.openclaw\openclaw.json' to be 'C:\custom\home\.openclaw\openclaw.json'

Root cause

The tests set OPENCLAW_HOME to a Unix-style absolute path like /custom/home, then assert the derived value equals path.resolve("/custom/home/.openclaw").

On Windows, path.resolve("/custom/home/.openclaw") resolves relative to the current drive, producing C:\custom\home\.openclaw. However, the production config module receives the raw env value and joins/normalises it without resolving against the current drive — producing \custom\home\.openclaw (no drive letter prefix).

The mismatch is between the test's path.resolve() expectation (which adds the drive letter) and the config module's actual path construction (which does not).

Reproduction

This is not flaky — it fails deterministically on every Windows CI run. Confirmed on at least:

• fix/12053-bluebubbles-dedup — run 21805708433
• fix/11630-chat-history-heartbeat-filter — run 21805777756

Suggested fix

Either:

• Option A: Use path.join() instead of path.resolve() in the test expectations so the assertion matches what the production code actually produces.
• Option B: Ensure the production config code calls path.resolve() on the final derived path, so the drive letter is always present on Windows.

Option B is likely more correct — paths without a drive letter on Windows can resolve to unexpected locations depending on the process's current drive.