codewhale-tui serve --mcp panics: 'Cannot drop a runtime in a context where blocking is not allowed'

[Neo-millunnium]

Bug Description

Running codewhale-tui serve --mcp crashes immediately with a panic in the tokio runtime:

thread 'main' panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.49.0/src/runtime/blocking/shutdown.rs:51:21:
Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.

Full Stack Trace

stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: tokio::runtime::blocking::shutdown::Receiver::wait
   3: tokio::runtime::blocking::pool::BlockingPool::shutdown
   4: core::ptr::drop_in_place<tokio::runtime::blocking::pool::BlockingPool>
   5: codewhale_tui::mcp_server::McpServer::run
   6: codewhale_tui::mcp_server::run_mcp_server
   7: codewhale_tui::main::{{closure}}
   8: tokio::runtime::park::CachedParkThread::block_on
   9: codewhale_tui::main

To Reproduce

# After installing codewhale@0.8.47
codewhale-tui serve --mcp

Environment

• codewhale version: 0.8.47 (7074399)
• codewhale-tui version: 0.8.47 (7074399)
• OS: Ubuntu 24.04.4 LTS, Linux 6.8.0-117-generic x86_64
• Architecture: x86_64

Analysis

The panic originates from codewhale_tui::mcp_server::McpServer::run (frame #5). The error message indicates that a tokio::runtime is being dropped while already inside an asynchronous context. This typically happens when:

1. The McpServer::run() method creates its own tokio runtime internally (e.g. via tokio::runtime::Runtime::new()), AND
2. That runtime is dropped while the outer #[tokio::main] runtime (frame Roadmap: build long-session evals for coherence and context handling #7→Roadmap: finish workspace extraction and remove runtime integration seams #8) is still active.

The blocking pool drop guard (BlockingPool::shutdown) detects this nested-drop scenario and panics.

Suggested Fix

In codewhale_tui::mcp_server::McpServer::run, avoid creating a new tokio runtime if one already exists. Instead, use tokio::runtime::Handle::current() or accept an existing runtime handle, so the inner code runs on the same runtime as the outer #[tokio::main] context.

If run() must create a new runtime, it should be done before entering any async context (i.e. before #[tokio::main]), or the method should be refactored to accept a &tokio::runtime::Handle.

Workaround

None currently available — the process exits immediately on launch.

---

This issue was filed based on a reproducible failure on a headless Ubuntu 24.04 server.