Corrupted session metadata prevents resume without recovery

[morluto]

What version of Kimi Code is running?

main at f06eb5c60e0a4e51162d1854dda1db41892b457c

Which open platform/subscription were you using?

Not provider-specific; this occurs while loading locally persisted session metadata.

Which model were you using?

Not model-specific.

What platform is your computer?

Source-level reproduction; the affected writers include local and SSH persistence paths.

What issue are you seeing?

If a session's state.json contains incomplete or otherwise invalid JSON, resuming that session rejects before any agent is reconstructed. The conversation records under the session's agent directories are stored separately, but the normal resume path cannot reach them without manually repairing the metadata.

The repository already has a test that reproduces this by replacing state.json with {bad json; resumeSession() rejects and records session_load_failed with a SyntaxError.

What steps can reproduce the bug?

1. Create a session.
2. Close it.
3. Replace the session's state.json contents with incomplete JSON such as {bad json.
4. Attempt to resume the session.
5. Observe that resume rejects before the main agent is reconstructed.

This is a deterministic malformed-file reproduction. An interruption during an in-place overwrite is a plausible way to produce such a file, but this report does not claim an observed production interruption.

What is the expected behavior?

Updating session metadata should not expose partially written JSON at the final path. If metadata is already invalid, resume should report an actionable session.state_invalid error while preserving the damaged file; it should not silently construct a session from empty or default metadata.

Automatic backup recovery is a separate policy decision. If added later, it should only accept a validated, known-good copy and should make recovery visible to the user.

Additional information

Confirmed source behavior

• Session.writeMetadata() serializes writes but calls persistenceKaos.writeText() on the final state.json path.
• Local Kaos.writeText() uses writeFile() and SSH Kaos.writeText() uses an SFTP write on the final path.
• Offline rename and archive, fork, and fork-at-turn operations also call writeFile() on the final state.json path.
• Session.resume() calls readMetadata() before reconstructing agents. readMetadata() currently passes raw JSON.parse() failures through rather than translating them to the existing public session.state_invalid error.

metadata change
      |
      v
write final state.json in place
      |
      +-- write completes --> valid new metadata
      |
      `-- write interrupted (hypothesis) --> partial JSON
                                             |
                                             v
                                      next resume rejects
                                      before agent replay

Proposed direction

Use same-directory temporary-file replacement for every production state.json writer:

1. Write and close the complete temporary file.
2. Replace the final path atomically where the backend supports it.
3. Clean up the temporary file if replacement does not happen.
4. Keep the existing live-session write queue so later metadata still wins.
5. Translate malformed persisted metadata to session.state_invalid, preserving the cause and the on-disk file.

The implementation needs an explicit persistence-abstraction contract because live metadata can use local or SSH-backed Kaos. Backup creation or automatic fallback is intentionally not required by this issue.

Acceptance criteria

• A failed/interrupted write before replacement leaves the previous valid state.json readable.
• Live and offline session metadata mutations use the crash-safe replacement path.
• Malformed JSON returns the existing actionable session.state_invalid error.
• Invalid metadata is never silently replaced with {} or default session metadata.
• The serialized live metadata queue retains latest-write-wins behavior.

No directly related issue or pull request was found in a narrow search for state.json corruption, session resume, and atomic session metadata writes.