Best possible solution:

Keep recovery at the session-loader boundary, trigger it only for an existing corrupt primary store, validate every recovery candidate before reading, reject fresh/in-flight temps, and cover the real fs-safe temp prefix.

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

Yes. By source inspection, writing a zero-byte or malformed sessions.json with a valid sibling .bak or temp artifact and then calling loadSessionStore leaves current main with an empty store instead of recovery.

Is this the best way to solve the issue?

No. The loader boundary is the right place, but this PR is not yet the best fix because it recovers outside proven corrupt-primary cases and trusts backup/fresh temp artifacts too broadly.

Full review comments:

• [P2] Gate recovery to corrupt existing primary stores — src/config/sessions/store-load.ts:176
  The gate still includes Object.keys(store).length === 0, and missing files also set primaryReadFailed, so a valid empty {} store or missing primary can restore stale .bak state. Split this into an explicit existing-corrupt/zero-byte/non-object primary signal before trying recovery.
  Confidence: 0.98
• [P2] Validate backup artifacts before parsing — src/config/sessions/store-load.ts:182-183
sessions.json.bak is read and parsed before any lstat, regular-file, symlink, or hardlink validation. Since this imports private session metadata as trusted recovery state, apply the same candidate validation before reading the backup file.
  Confidence: 0.93
• [P2] Reject fresh temp recovery candidates — src/config/sessions/store-load.ts:218-221
  Temp candidates are accepted solely by name and file shape, then sorted oldest-first. If the only matching artifact is from an active writer, a transient primary read failure can import an in-flight temp despite the PR's stated freshness mitigation.
  Confidence: 0.88
• [P2] Use the actual fs-safe temp prefix in recovery tests — src/config/sessions/store-load.recovery.test.ts:87-88
  These fixtures use .sessions.json.<pid>.<uuid>.tmp, but the pinned fs-safe atomic helper creates .fs-safe-replace.<pid>.<uuid>.tmp and the loader regex matches that prefix. The advertised fs-safe recovery tests currently miss the intended branch and should use the real temp pattern.
  Confidence: 0.96

Overall correctness: patch is incorrect
Overall confidence: 0.95

Security concerns:

• [medium] Backup recovery follows unvalidated artifacts — src/config/sessions/store-load.ts:182
  The backup path is read and parsed before link and hardlink validation, so a linked sessions.json.bak can be imported as trusted private session state.
  Confidence: 0.91
• [low] Fresh temp recovery can race active writers — src/config/sessions/store-load.ts:218
  Matching temp files are accepted without a freshness threshold, allowing an active writer's temp artifact to be imported after a primary read failure.
  Confidence: 0.86

Acceptance criteria:

• pnpm test src/config/sessions/store-load.recovery.test.ts src/config/sessions/store.pruning.integration.test.ts
• pnpm exec oxfmt --check --threads=1 src/config/sessions/store-load.ts src/config/sessions/store-load.recovery.test.ts src/config/sessions/store-validation.ts CHANGELOG.md
• pnpm check:changed

What I checked:

• Current main lacks recovery: loadSessionStore catches final read/parse failure and continues with the initialized empty store; there is no .bak or temp artifact fallback before returning. (src/config/sessions/store-load.ts:125, 7d00183d44b2)
• PR recovery gate remains too broad: The PR gates recovery on primaryReadFailed || Object.keys(store).length === 0, so a valid empty store or missing primary can still restore stale artifacts. (src/config/sessions/store-load.ts:176, 6dc1c0d63ad2)
• Backup is parsed before validation: sessions.json.bak is read and parsed before the regular-file, symlink, and hardlink checks used for temp candidates. (src/config/sessions/store-load.ts:182, 6dc1c0d63ad2)
• Temp freshness mitigation is absent: Temp candidates are accepted after shape checks and sorted oldest-first, but no age threshold rejects an active writer's fresh temp artifact. (src/config/sessions/store-load.ts:218, 6dc1c0d63ad2)
• fs-safe temp contract mismatch in tests: The pinned @openclaw/fs-safe helper builds .fs-safe-replace.<pid>.<uuid>.tmp, while the new fs-safe recovery tests create .sessions.json.<pid>.<uuid>.tmp. (src/config/sessions/store-load.recovery.test.ts:87, 6dc1c0d63ad2)
• Real behavior proof supplied: The PR body includes copied terminal output from a real gateway restart after simulated corruption showing a self-healed session store from backup/tmp log with recovered entries. (6dc1c0d63ad2)

Likely related people:

• shakkernerd: GitHub commit history shows the current session-store loader split came from c2e93c76bd43, with later session-store touches in the same area. (role: introduced loader split and adjacent maintainer; confidence: high; commits: c2e93c76bd43, 6395336454e0; files: src/config/sessions/store-load.ts, src/config/sessions/store.ts)
• steipete: Recent history includes session-store writer queue, durable-write, rotation removal, and fs-safe extraction work around the affected storage boundary. (role: heavy session-store and fs-safe maintainer; confidence: high; commits: 897bac5b8cd3, b4437047f477, fb40ed99a7f0; files: src/config/sessions/store.ts, src/config/sessions/store-load.ts, src/infra/json-files.ts)
• vincentkoc: Recent commits touched deferred session-store read maintenance and fs-safe non-durable and hardlink-safe filesystem behavior relevant to recovery trust rules. (role: recent adjacent maintainer; confidence: medium; commits: bf8bdcb064ee, 11a038207b95, 3a89e20b7b5f; files: src/config/sessions/store-load.ts, src/infra/json-files.ts, src/infra/replace-file.ts)

Remaining risk / open question:

• Concurrent writer behavior on NFS/SMB remains unproven, and the PR body also calls that out as untested.

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