Thanks @wali-reheman — this is a good catch.

Confirmed the leak: in api/streaming.py ~L1885, the cached-agent reuse path overwrites agent._session_db without closing the previous instance. Each SessionDB.__init__ opens a SQLite connection that holds three FDs once WAL kicks in (state.db, state.db-wal, state.db-shm), and they're never released because nothing else holds a reference to the old object once agent._session_db is rebound. After enough chat turns on a long-lived agent, EMFILE is the predictable end state.

Your fix shape matches what SessionDB.close() is designed for — it grabs the internal lock, runs PRAGMA wal_checkpoint(PASSIVE), then closes the connection and nulls _conn. Wrapping it in try/except Exception: pass is right: a busted WAL checkpoint shouldn't block the new session from being installed.

Two things I'll verify on my side before merging:

1. No double-close races. Want to make sure no other code path (cancel handler, finally block in the streaming generator, agent destructor) closes the same _session_db after we've already swapped it. SessionDB.close() is idempotent (if self._conn:), so worst case is benign, but I'd like to confirm the swap point is the only owner.
2. FD-count regression test. Going to add a small test that drives N streaming requests through the cached-agent reuse path and asserts the open-FD count for state.db* stays bounded.

Will run the full pytest suite (3604 tests on master) plus the browser harness today and aim to merge in the next batch release.

Repro detail you mentioned — 73 handles at the EMFILE crash matching exactly the message count — is solid evidence and worth pinning in the test. Thanks again.