fix(server): subscribe before provider settings watcher

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}

[t3-code]

summary

• acquire the server settings subscription before forking the provider instance watcher
• add a deterministic regression test for settings updates published before a lazy stream starts

testing

• vp test run apps/server/src/provider/Layers/ProviderRegistry.test.ts
• targeted regression test passed 25 consecutive runs
• vp lint apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts
• vp run --filter t3 typecheck
• vp fmt --check apps/server/src/provider/Layers/ProviderInstanceRegistryHydration.ts apps/server/src/provider/Layers/ProviderRegistry.test.ts

request provenance

• requested by: @maria-rcks

---

Note

Medium Risk
Touches hot-reload of provider registry config from settings; incorrect subscription timing could still miss updates or duplicate work, but scope is limited to the hydration watcher path.

Overview
Fixes a race where provider instance registry hydration could miss server settings updates if they were published before the background watcher actually subscribed.

SettingsWatcherLive now yields ServerSettingsService.subscribeChanges in the layer-building fiber, then forks runForEach on that stream. That registers the PubSub subscription before the daemon starts, instead of deferring subscription to a lazily evaluated streamChanges inside the forked fiber.

A regression test wraps streamChanges in a deferred lazy stream: it publishes a Codex binaryPath change first, then only then allows the stream to start. The test expects a second probe for the new binary—behavior a pre-subscribe watcher would fail.

^{Reviewed by Cursor Bugbot for commit f9dcc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Subscribe to settings changes before forking SettingsWatcherLive watcher fiber

The settings watcher previously consumed the serverSettings.subscribeChanges stream directly inside the forked pipeline, so updates published before the stream started could be missed. It now acquires the subscription into a local stream value first, then runs that stream in the scoped fiber.

• The re-probe integration test is updated to publish a binary-path update before the lazily exposed change stream starts, and verifies the registry still re-probes Codex with the new path.
• Risk: the subscribeChanges acquisition happens earlier in the layer lifecycle; providers that emit changes during layer composition now rely on the subscription being live before the fork.

^{Macroscope summarized f9dcc19.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−5 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−8 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−4 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: b57726c · PR result: f9dcc19 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at f9dcc19

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that acquires an existing settings subscription before starting the watcher, preventing missed provider reconfiguration events without changing schemas, defaults, or unrelated runtime paths. The added test deterministically covers the startup race.

^{You can add or adjust custom eligibility rules. Learn more.}