[Bug]: Setting runtime mode to "auto" bricks the app — startup decoder rejects persisted value, backend crash-loops #4518

Summary

Setting a thread's runtime mode to auto persists the literal value auto to the local database, but the thread-list decoder on startup only accepts approval-required / auto-accept-edits / full-access. The backend server then crashes on every subsequent launch, so the app can never start again until the row is fixed by hand.

Environment

• T3 Code Desktop 0.0.28 (Linux x86_64, Arch/CachyOS, Wayland)
• Provider: Claude agent

Steps to reproduce

1. Open any thread and switch its runtime mode to auto in the UI.
2. Quit T3 Code.
3. Launch it again.

Expected

App launches and lists threads.

Actual

The desktop shell starts, but the backend child exits with code 1 about a second after boot and keeps crash-looping. From ~/.t3/userdata/logs/server-child.log:

ERROR (#1): PersistenceDecodeError: Decode error in ProjectionSnapshotQuery.getCommandReadModel:listThreads:decodeRows: Composite(Pointer(Composite(Pointer(AnyOf()))))
    at PersistenceDecodeError.fromSchemaError (file:///opt/t3code-bin/resources/app.asar/apps/server/dist/bin.mjs:8584:10)
    ...
  [cause]: SchemaError: Expected "approval-required" | "auto-accept-edits" | "full-access", got "auto"
    at [1]["runtimeMode"]

The write path accepts the mode change fine — moments earlier the same log shows the provider command reactor processing it:

INFO (#174): provider command reactor restarting provider session
  { ..., currentRuntimeMode: 'full-access', desiredRuntimeMode: 'auto', runtimeModeChanged: true, ... }

So the row lands in projection_threads.runtime_mode as auto, and the read model's schema rejects it forever after.

Workaround

Fix the row manually while the app is closed:

-- ~/.t3/userdata/state.sqlite
UPDATE projection_threads SET runtime_mode = 'approval-required'
WHERE runtime_mode = 'auto';

App launches normally afterwards. Clicking auto again re-breaks it the same way.

Suggested fix

Either add auto to the persisted runtimeMode schema, or normalize it to a concrete mode before persisting — and ideally make listThreads skip/heal undecodable rows instead of taking the whole backend down.