[Bug]: Client clock skew persists future timestamps and reorders thread messages

[Fr4nzz]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (triggered by timestamps supplied by apps/web and apps/desktop)

Steps to reproduce

1. Start a T3 Code server on a machine whose clock is correct.
2. Connect from the web or desktop client on another machine whose system clock is ahead (confirmed with a +5-hour offset on a Windows dual-boot installation).
3. Send a prompt and allow its response to complete.
4. Correct the client clock, or connect from a client with the correct clock, and send another prompt in the same thread.
5. Reload or reopen the thread.

Expected behavior

Persisted conversation chronology should use a canonical server-side timestamp (or otherwise tolerate clock skew). A client clock error should not create future-dated messages/events or cause an older prompt to render after its response and after genuinely newer prompts.

Actual behavior

The prompt sent by the skewed client is persisted with the future client timestamp. The thread is then ordered by that timestamp, so the older prompt appears at the bottom, after its assistant response and after newer prompts sent from a correct-clock client.

Correcting the Windows clock prevents newly sent prompts from being future-dated, but it does not repair existing records.

Impact

Major degradation or frequent failure. Conversation chronology becomes misleading across desktop and web clients, and the bad timestamp also propagates into related thread/turn metadata.

Version or commit

0.0.29-nightly.20260712.791

Environment

Windows 11 web and desktop clients connected to a Linux headless T3 Code server over a private remote network. Windows clock was exactly 5 hours ahead; Linux/server clock was correct.

Logs or stack traces

Local SQLite inspection (message contents and identifiers omitted):
- 16 future-dated user messages across 3 threads
- each affected user-message timestamp was exactly 5 hours ahead
- subtracting 5 hours placed each prompt 0.6–9 seconds before the next server event
- SQLite integrity_check: ok

Packaged source maps for this nightly show the client generating createdAt with:
 new Date().toISOString()

The server orchestration path then uses command.createdAt for persisted event timestamps and payloads. The message projection preserves that value, and thread messages are loaded with:
 ORDER BY created_at ASC, message_id ASC

This appears related to #2087 and the fix in #2408, but those concern visit-state/React behavior when the client clock lags the server. This report is about canonical message/event ordering when the client clock is ahead of the server.

Screenshots, recordings, or supporting files

Not attached because the original thread contains private conversation content. The deterministic database evidence above was collected without exposing message contents, hostnames, IP addresses, tokens, or local paths.

Workaround

Synchronize/correct every client machine's clock before sending messages. There does not appear to be a supported way to repair timestamps already persisted.

Suggested fix: assign canonical createdAt/occurredAt values at server receipt time and retain the client timestamp separately if it is useful for diagnostics. Alternatively, validate and clamp/reject implausible client timestamps. A repair or migration path for already future-dated events/projections would also help.