Area
apps/server
Problem
ProviderSessionReaper stops any provider session idle for 30 minutes, sweeping every 5 minutes. Both values are hardcoded in apps/server/src/provider/Layers/ProviderSessionReaper.ts:
const DEFAULT_INACTIVITY_THRESHOLD_MS = 30 * 60 * 1000;
const DEFAULT_SWEEP_INTERVAL_MS = 5 * 60 * 1000;
The ProviderSessionReaperLiveOptions interface exists, but the shipped layer is constructed with no arguments (ProviderSessionReaperLive = makeProviderSessionReaperLive()), and no env var, settings.json key, or RPC patch field feeds it. For users with long-running research/agent threads, every pause longer than 30 minutes costs a session teardown and a cold resume on the next message (see #4198 for the related staleness bug). The only workaround today is patching bin.mjs in the installed service and restarting, which does not survive t3 service update.
Proposal
Add two server settings, providerSessionInactivityThreshold and providerSessionSweepInterval (persisted as millis, defaults unchanged: 30 min / 5 min), consumed by the reaper. The threshold can be re-read every sweep so settings edits apply live; the sweep interval is read once at start(). Explicit ProviderSessionReaperLiveOptions keep precedence so existing test seams are untouched.
One placement question for maintainers: should these be flat ServerSettings fields, or live in the backgroundActivity profile system next to idleClientTtl / providerHealthRefreshInterval so they vary per power profile? A PR implementing the flat variant (smaller diff) is attached; happy to rework it into BackgroundActivityOverrides if that is the preferred shape.
Written by Claude Fable 5 via Claude Code on behalf of a self-hosted user.
Area
apps/server
Problem
ProviderSessionReaperstops any provider session idle for 30 minutes, sweeping every 5 minutes. Both values are hardcoded inapps/server/src/provider/Layers/ProviderSessionReaper.ts:The
ProviderSessionReaperLiveOptionsinterface exists, but the shipped layer is constructed with no arguments (ProviderSessionReaperLive = makeProviderSessionReaperLive()), and no env var, settings.json key, or RPC patch field feeds it. For users with long-running research/agent threads, every pause longer than 30 minutes costs a session teardown and a cold resume on the next message (see #4198 for the related staleness bug). The only workaround today is patchingbin.mjsin the installed service and restarting, which does not survivet3 service update.Proposal
Add two server settings,
providerSessionInactivityThresholdandproviderSessionSweepInterval(persisted as millis, defaults unchanged: 30 min / 5 min), consumed by the reaper. The threshold can be re-read every sweep so settings edits apply live; the sweep interval is read once atstart(). ExplicitProviderSessionReaperLiveOptionskeep precedence so existing test seams are untouched.One placement question for maintainers: should these be flat
ServerSettingsfields, or live in thebackgroundActivityprofile system next toidleClientTtl/providerHealthRefreshIntervalso they vary per power profile? A PR implementing the flat variant (smaller diff) is attached; happy to rework it intoBackgroundActivityOverridesif that is the preferred shape.Written by Claude Fable 5 via Claude Code on behalf of a self-hosted user.