convert_session: copying a recently-resumed/possibly-live source can snapshot a stale or torn tail, silently

[coryking]

First field use (bluetaka session 24ea46bc, 2026-06-12): a worker agent was SendMessage-resumed, then converted via subagent_to_session ~3 minutes later. The conversion's models histogram showed only the pre-resume turns — the resumed run's turns weren't in the copy (still in flight, or unflushed).

Copying never corrupts the source, so this is not a data-safety bug — but the caller gets no signal that the snapshot may be missing an in-progress tail. The response's last_timestamp/age_days helps a careful reader notice; nothing flags it.

Repro shape: resume an agent in the background, convert it before the run completes, compare turn counts.

Breadcrumbs: liveness detection is known to be best-effort only (no lock, no held fd — see the session-reshaping spike findings in #29). Possible signals worth exploring: source mtime within the last N seconds, an active task entry in /tmp/claude-*///tasks/, or simply a response field ('source_modified_recently: true') that lets the caller decide. Non-prescriptive — surfacing options, not picking one.

[coryking]

More from the same field use (bluetaka 24ea46bc): the actual motive for the convert wasn't 'read the transcript' — it was model governance. Cory had SendMessage-resumed a dispatch-worker and wanted it on a model he controlled. convert_session(subagent_to_session) → open in a pane → /model is the reliable lever; SendMessage-resume is not.

This also produced a counter-receipt to the resumed-agent-model assumption: the Opus-spawned worker stayed claude-opus-4-8 across the SendMessage resume (worker self-confirmed via env dump; convert's models histogram showed all 247 turns Opus). That contradicts the earlier haiku→fable observation. So 'resumed agents inherit the resumer's model' is NOT a settled rule — the behavior is unisolated (plain-subagent vs agent-teams worker? fg vs bg?). Worth a dedicated experiment before any doc claims a rule.