Agent runtime note · 2026-08-24
Session isolation is not a logging detail
A process-global fallback looks harmless until two agent sessions run at the same time.
Agent CLIs often begin life with one process, one conversation, and one global session object. Concurrency arrives later. The dangerous part is that the old fallback can keep working in single-session tests long after it has become wrong in production.
The misleadingly small symptom
A debug-log helper in Qwen Code could consult global session state before the active session context. Under concurrent runs, diagnostics from one session could therefore be associated with another session’s transcript. The log line itself was fine; its owner was not.
The fix in PR #9538makes the context-local session authoritative and keeps the global object only as a compatibility fallback. A related change in PR #9471applied the same boundary to fork-cache readers.
How to prove isolation
A good isolation test needs at least two live identities. Set a distinct sink or cache reader in each session, interleave the operations, and assert that every observation returns to its own owner. Testing session A and then session B sequentially can leave a global fallback looking correct.
Context propagation is not plumbing when the context decides who owns the data.
The reusable rule
Search global fallbacks whenever a formerly single-tenant runtime becomes concurrent. Logging, caches, debug sinks, and transcript writers are especially easy to dismiss as secondary—even though they often carry user-specific state.