Crash loop: TypeError when session.json exists but sessionId is missing

[charzphone]

Bug

runner.ts crashes in a tight loop when session.json exists but is missing the sessionId field. The daemon restarts via watchdog, crashes again on the next heartbeat, and repeats indefinitely.

Root cause

getSession() in sessions.ts reads session.json and returns the parsed object. If the file contains {"turnCount":0,"compactWarned":false,"lastUsedAt":"..."} (no sessionId or createdAt), getSession() returns a truthy object with sessionId: undefined.

In runner.ts (~line 1010):

const isNew = !existing;

existing is truthy (it's an object), so isNew is false. Then ~line 1047:

console.log(
  `... (${isNew ? "new session" : `resume ${existing!.sessionId.slice(0, 8)}`} ...)`
);

existing!.sessionId is undefined, so .slice() throws:

TypeError: undefined is not an object (evaluating 'existing.sessionId.slice')

How the corruption happens

I'm not 100% sure what originally wrote the incomplete session.json, but it may be a race between a session write and a crash/kill, or an edge case in the session-creation path where the file is written before sessionId is assigned.

Fix

- const isNew = !existing;
+ const isNew = !existing || !existing.sessionId;

This treats a corrupted session (missing sessionId) as a new session, triggering a fresh bootstrap instead of crashing.

A secondary hardening could also be applied at line ~1047:

- `resume ${existing!.sessionId.slice(0, 8)}`
+ `resume ${existing!.sessionId?.slice(0, 8) ?? "unknown"}`

Environment

• ClaudeClaw v1.0.27
• Bun runtime on Windows 10
• Crash confirmed in daemon log with 3+ restart cycles before manual intervention

Workaround

Delete the corrupted session.json and restart the daemon. A fresh session bootstraps normally.

[TerrysPOV]

Great repro and root cause — this is exactly right. A session.json that's parseable JSON but missing sessionId slips past the !existing check, and then .slice() blows up.

Your proposed fix is the right shape. If you want to send a PR, I'd take both changes you sketched:

1. const isNew = !existing || !existing.sessionId; to treat the corrupted file as a fresh bootstrap
2. The optional-chain on the log line as a defence-in-depth guard for similar drift

A test case for the corrupted-file path would seal it — even a tiny one in the existing test suite is enough.

Quick note on workflow: when you open the PR please run both bun run bump:plugin-version and bun run bump:marketplace-version and include those commits — the two version-guard checks block merge otherwise.

Thanks for the careful write-up.

[rudi193-cmd]

PR: #234 — implements both items from your review (hasValidSessionId guard + isNew = !existing?.sessionId). Corrupted session.json now bootstraps instead of crash-looping.