MCP use hangs permanently in TUI mode (cli mode works perfectly).

[tomjuggler]

Issue

when asked to use an MCP like Context7 the agent happily obliges - but this results in the interface just hanging forever (Processing...)

This only happens in TUI mode.

Unable to use ESC or Ctrl+C to cancel the request - have to kill Cecli to stop.

Version and model info

cecli v0.100.5
No sub-agents
DeepSeek (tested both models)

[dwash96]

Anything in .cecli/logs/mcp-errors.log ?

[tomjuggler]

Sorry I don't see any errors there.
Only this line:
Context7 Documentation MCP Server v3.1.0 running on stdio

[tomjuggler]

That line only showed up once, I tried again after deleting it and it didn't show up. It was definitely put there by a tui session that hung

[tomjuggler]

If it helps this is my .cecli.conf.yml:

dark-mode: true
light-mode: false
auto-commits: true
agent: true
analytics: false
auto-save: true
auto-load: false
cache-prompts: true
check-update: true
debug: false
enable-context-compaction: true
env-file: .aider.env
multiline: false
preserve-todo-list: true
show-model-warnings: true
watch-files: false
tui: true
yes-always: true

agent-config: |
  {
    "skills_paths": ["~/skills", "./.cecli/skills"],  
    "subagent_paths": [".cecli/subagents"],
    "max_sub_agents": 5,
    "allow_nested_delegation": false,
    "large_file_token_threshold": 12500,
    "skip_cli_confirmations": true
  }

mcp-servers: |
  {
    "mcpServers": {
      "context7": {
        "type": "stdio",
        "command": "npx",
        "args": ["-y", "@upstash/context7-mcp"],
        "env": {
          "DEFAULT_MINIMUM_TOKENS": "6000"
        },
        "autoApprove": ["resolve-library-id", "get-library-docs"],
        "alwaysAllow": ["resolve-library-id", "get-library-docs"]
      },
      "fetch": {
        "type": "stdio",
        "command": "uvx",
        "args": ["mcp-server-fetch"]
      },
      "brainfile": {
        "type": "stdio",
        "command": "npx",
        "args": ["@brainfile/cli", "mcp"]
      }
    }
  }

I don't have any sub-agents configured though, just one skill to do with Brainfile usage (also not working here)

[devsoft-co-za]

I am trying to debug this with Cecli but so far this is all I got:

Based on my thorough investigation of the codebase, logs, and chunk data, here's my complete analysis:

## Root Cause Analysis: TUI-only MCP stdio hang

### What happens (code flow)

1. **First LLM call completes** → `chunks.log` confirms this: 96 chunks streaming the `context7--resolve-library-id` tool call from `deepseek-v4-flash`
2. **`send_message()`'s `finally` block runs** → shows `"Processing Answer..."` spinner
3. **`process_tool_calls()`** → calls `confirm_ask("Run tools?")` → user confirms → MCP tool executes → result returned → `reflected_message = True`
4. **`send_message()` returns** → back to `run_one()`'s reflection loop
5. **`send_message(None)` is called next** (because `reflected_message is True` → `message = None`)
6. **Second LLM call starts** → but this is where it hangs

### Why the chunks.log proves this

The chunks.log shows **only one** streaming session — ending with `finish_reason='tool_calls'` and usage stats (`completion_tokens=139`). There are **zero chunks** from a 
second LLM response. If the reflection worked, there would be a second batch of chunks after the tool result was submitted.

### The critical clue

The hang is **TUI-only** and happens with **any stdio MCP** (not just Context7). The second LLM call in step 5 never produces any streaming chunks. The `format_messages()` at 
the start of `send_message()` is called via `run_in_executor(None, self.format_messages)` which runs in a thread pool — and in TUI mode, the coder runs in a **background 
thread** (via `CoderWorker`), creating **two layers of threading** that could cause issues.

### Most likely causes

1. **Threading deadlock**: The `run_in_executor` for `format_messages()` combined with the CoderWorker's background thread creates a nested threading situation that deadlocks 
in TUI mode
2. **Context compaction blocking**: After tool results, the conversation is much larger. If `compact_context_if_needed()` is triggered, its `summarize_all_as_text()` calls the 
weak/secondary model — which could hang the same way
3. **`format_chat_chunks()` in AgentCoder**: The enhanced context blocks (`_calculate_context_block_tokens()`, `get_context_symbol_outline()`) use `repo_map.get_tags_raw()` 
which may block in the threaded context

#2 is not likely, test run with little context

I hope this helps - not sure how much further I can get on my own

[devsoft-co-za]

I don't know what happened I got mcp to work now in tui mode - possibly broke a lot of other stuff though?

https://github.com/devsoft-co-za/aider-ce/tree/background_thread_mcp_fix

Please try to ignore all of the debug stuff I added!

[devsoft-co-za]

issue remains in 0.100.6 (my "fix" based on 0.100.4) - sorry I just saw the update now

[tomjuggler]

That did it! Thank you so much!!