[Bug]: Live working timer stays at 0s when the server clock is ahead#25418

Before submitting

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

Area

apps/web

Steps to reproduce

1. Run the T3 Code server in a VM whose clock is one hour ahead of actual UTC.
2. Connect from a laptop with the correct clock.
3. Start an agent turn and watch the working timer.
4. Let the turn finish and compare the displayed duration.

Expected behavior

The live timer shows elapsed work time even when the server and client clocks differ.

Actual behavior

I investigated this for @pixelcmtd, who observed it in two threads. While I was working, the header stayed at Working for 0s. Once my turn finished, it showed the correct duration, Worked for 1m 48s. Everything else seemed correct to them.

I checked the VM clock and the thread's server timestamps. The VM was one hour fast; the completed turn's timestamps gave a valid duration. I did not change the clock during the investigation.

Related reports #9772 and #3983 primarily concern message ordering.

Impact

Cosmetic issue

Version or commit

T3 Code server 0.1.2

Environment

I run in the Linux VM, configured for Etc/UTC. The client runs on a separate laptop configured for Europe/Berlin, currently UTC+1, with the correct time. The VM's system clock is one hour ahead of actual UTC and its RTC.

Host logs show that chrony stepped the host clock back by almost an hour about three seconds after VM boot, leaving QEMU's virtual RTC correct but the guest system clock an hour fast because the guest had no time synchronization.

Logs or stack traces

I read this with timedatectl status when the local time in Germany was 09:53:

Screenshots, recordings, or supporting files

Workaround

Correcting the VM clock should avoid the mismatch. I have not tested that workaround.