Symptom
After a manual attach to an existing CLI session (e.g. via a session-manager tool), the binding is invalidated on the very first turn. Any subsequent turn behaves as a fresh session, defeating the purpose of attach.
Root cause
resolveCliSessionReuse re-validates the underlying CLI session's hash on every turn and treats any drift as "this isn't the same session anymore". For a freshly attached session that has accrued state since the snapshot was taken, drift is guaranteed — so attach effectively always invalidates on turn 1.
Suggested fix
Add a forceReuse: true short-circuit at the top of resolveCliSessionReuse. When the caller has explicitly asked to reuse a binding (manual attach is the canonical case), skip the hash check and trust the binding.
Affected dist file
cli-session-*.js
Workaround
We've been running a local runtime patch since 2026-04-29. Happy to PR.
Symptom
After a manual attach to an existing CLI session (e.g. via a session-manager tool), the binding is invalidated on the very first turn. Any subsequent turn behaves as a fresh session, defeating the purpose of attach.
Root cause
resolveCliSessionReusere-validates the underlying CLI session's hash on every turn and treats any drift as "this isn't the same session anymore". For a freshly attached session that has accrued state since the snapshot was taken, drift is guaranteed — so attach effectively always invalidates on turn 1.Suggested fix
Add a
forceReuse: trueshort-circuit at the top ofresolveCliSessionReuse. When the caller has explicitly asked to reuse a binding (manual attach is the canonical case), skip the hash check and trust the binding.Affected dist file
cli-session-*.jsWorkaround
We've been running a local runtime patch since 2026-04-29. Happy to PR.