Hmbown/CodeWhale · error

Failed to sync thread session: {e}

Error message

Failed to sync thread session: {e}

What it means

Wrapper raised when the engine.send(Op::SyncSession ...) call fails while (re)attaching a thread: the engine could not accept the session sync carrying session_id, prior messages, system prompt, route model, workspace, and policy projection. The inner {e} carries the engine-side cause; typically a closed op channel or an engine task that is shutting down.

Source

Thrown at crates/tui/src/runtime_threads.rs:6806

                .map(|s| SystemPrompt::Text(s.clone()));
            if !session_messages.is_empty() || sys_prompt.is_some() {
                engine
                    .send(Op::SyncSession {
                        session_id: thread.session_id.clone(),
                        messages: session_messages,
                        system_prompt: sys_prompt,
                        system_prompt_override: thread.system_prompt.is_some(),
                        model: route_model.clone(),
                        workspace: thread.workspace.clone(),
                        mode: RuntimePolicyProjection::from_persisted(
                            &thread.mode,
                            thread.permission_posture.as_deref(),
                            thread.auto_approve,
                        )
                        .mode,
                    })
                    .await
                    .map_err(|e| anyhow!("Failed to sync thread session: {e}"))?;
            }

            let mut active = self.active.lock().await;
            if let Some(winner) = active
                .engines
                .get(&thread.id)
                .map(|state| state.engine.clone())
            {
                touch_lru(&mut active.lru, &thread.id);
                drop(active);
                engine.cancel_with_reason(crate::core::engine::CancelReason::Internal);
                let _ = engine.try_send(Op::Shutdown);
                return Ok(winner);
            }

            // Atomically compare the record used for construction with the latest
            // durable record while holding the same active -> thread lock order as
            // updates. A concurrent workspace/model/session/policy change makes

View on GitHub (pinned to 0c42157ee5)

Solutions

1. Check whether the engine task for this thread already shut down; restart the session and retry the attach
2. Inspect the inner error for engine-side rejection causes (bad session state, closed channel)
3. Avoid attaching the same thread from two processes simultaneously

When it happens

Trigger: Thrown at crates/tui/src/runtime_threads.rs:6806 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/4b35b8c10ccae946. Report an issue: GitHub.