Greptile Summary

This PR fixes a stale-snapshot race condition where a second WebSocket connection's agents.update would fail with "agent not found" because loadConfig() returned a cached in-memory snapshot that pre-dated a agents.create from another connection. The fix clears and refreshes the runtime snapshot from disk after each writeConfigFile, so any subsequent loadConfig() call (on the same process) sees the newly persisted state.

The approach taken — setRuntimeConfigSnapshot(fresh, nextCfg) — also resolves the previously flagged regression where runtimeConfigSourceSnapshot was left as null after a write, which would have caused subsequent writes to skip secret-preservation merge-patch and write plaintext secrets to disk.

Key changes:

• writeConfigFile now unconditionally calls clearRuntimeConfigSnapshot() after a successful write, invalidating the stale in-memory cache.
• When both snapshots previously existed (hadBothSnapshots), they are re-populated: fresh = loadConfig() (env-resolved config re-read from disk) becomes the new runtimeConfigSnapshot, and nextCfg (the source config written to disk, with secret refs intact) becomes the new runtimeConfigSourceSnapshot.
• The new test covers both the initial write and a follow-up write, asserting that apiKey remains a source ref on disk across both writes — directly addressing the test gap called out in the prior review.

Confidence Score: 4/5

• Safe to merge; the fix is logically sound and directly addresses both the stale-snapshot bug and the previously flagged secret-ref regression.
• The core logic is correct: fresh = loadConfig() obtains the env-resolved config from disk (confirmed by resolveConfigForRead in the ConfigIO.loadConfig implementation), and nextCfg correctly carries the source refs written to disk. The new test validates secret-ref preservation through two consecutive writes. One residual edge case: if loadConfig() throws after a successful write (e.g., corrupted JSON on the re-read), the caller receives an exception even though the write itself succeeded — but this is pre-existing risk in any read-after-write pattern and is not introduced by this PR.
• No files require special attention.

_{Last reviewed commit: 3df4457}

@greptile-apps review it

hi @gumadeiras , would you mind taking a look at this PR? Your feedback would be appreciated.

Merged via squash.

• Prepared head SHA: 69e1861abf97d20c787a790d37e68c9e3ae2cb1d
• Merge commit: 4ff4ed7ec97450b502ca3f456e3af8c7c19eff43

Thanks @bbblending!

Thanks @gumadeiras for building on this and hardening the fix — really appreciate it.