Host that doesn't drain Serena's stdout deadlocks the executor thread after ~N tool calls (via logging.emit)

[941design]

Filing in case it helps others seeing the "task stuck, every later tool call times out" symptom (e.g. #937, and the report further down that thread about calls constantly hitting timeout limits at scale).

We embed serena start-mcp-server (streamable-http transport) from a non-TypeScript host. We saw Serena freeze: after ~15 tool calls, every subsequent call — including pure-filesystem read_file / list_dir — timed out, permanently, regardless of language server (pyright and jedi both wedged identically).

A py-spy dump of the live server showed the cause:

• the executor thread parked in task_executor → wait_until_done → result(), waiting on the running task;
• the running task stuck in run_task → (sensai) logging → logging.emit → stream write.

The root cause was host-side: we spawned Serena with an undrained stdout pipe. Serena logs verbosely, so after enough calls the OS pipe buffer (~64 KB) fills, and Serena's next log write blocks on the single executor thread. Because that thread is also the only worker and the running task can't be cancelled, the server wedges for the life of the process. Our fix was simply to redirect Serena's stdout to a file (unbounded) instead of an unread pipe.

This is host-side and not strictly a Serena bug, but two things might help the project and others hitting the same symptom:

1. A docs note that MCP hosts must drain or redirect Serena's stdout/stderr (an unread pipe will deterministically deadlock the server).
2. Consider emitting server logs off the executor thread (or to a file/stderr by default), so an undrained host stdout can't block the worker.

Environment: Serena from git+https://github.com/oraios/serena (main), streamable-http, --context desktop-app; reproduced with both pyright and jedi backends. Happy to share the py-spy folded stacks if useful.