[Bug]: MCP write approval aborts the app on Linux — tokio panic "Cannot start a runtime from within a runtime" (v0.27.0)

Closed
  • Is something wrong?
#919 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
mysql, rust, tauri, typescript
Domain
backend-api-design, databases, desktop

Research direction

Start with the MCP write-approval path (approval queue, modal, and preflight) and inspect the suspected block_on calls in src-tauri/src/lib.rs, src-tauri/src/backup/mod.rs, and src-tauri/src/ssh_tunnel.rs. Reproduce on Linux with a write query that requires approval, then use a build with symbols or RUST_BACKTRACE=full to identify the nested runtime call. Done when approval runs the query without freezing or aborting the GUI.

Written by the indexing model from the issue text.

Description

On Linux, when an MCP client issues a write query (run_query) that requires approval and the Tabularis GUI is running, the GUI process freezes and then aborts (SIGABRT). Consequently the MCP subprocess (tabularis --mcp) returns:

Tabularis app closed during approval — open it to approve writes

The crash is a Rust panic on a Tokio worker thread:

thread 'tokio-rt-worker' panicked at
  tokio-1.50.0/src/runtime/scheduler/multi_thread/mod.rs:88:9:
Cannot start a runtime from within a runtime. This happens because a function
(like `block_on`) attempted to block the current thread while the thread is
being used to drive asynchronous tasks.

That location (multi_thread/mod.rs:88) is inside MultiThread::block_on, i.e. a block_on is being called from within an async context.

Environment

  • Tabularis 0.27.0 — AUR tabularis-bin 0.27.0-1 (built/installed 2026-10-08), also reproduced on the previous build.
  • Arch Linux, Hyprland (Wayland), x86_64; WebKitGTK 4.1.
  • MCP host: OpenCode v2, spawning tabularis --mcp over stdio.
  • Driver: built-in MySQL (MariaDB/MySQL connection).
  • tabularis-bin-debug is installed but appears to be a stub (no .debug_* sections, nm empty, addr2line returns ??), so no usable symbols for the crash site.

Steps to reproduce

  1. Start the GUI and configure the MCP server (tabularis --mcp) in an MCP host.
  2. Use an approval mode that requires approval for writes.
  3. From the MCP host, call run_query with a write statement (e.g. a simple UPDATE ...) on a non read-only connection.
  4. Observe: the GUI becomes unresponsive ("Application Not Responding"), then the process aborts.

Expected

The approval modal appears; approving runs the query; the app stays up.

Actual

  • GUI freezes, then the process receives SIGABRT on a tokio-rt-worker thread (si_code: SI_TKILL, self-sent).
  • systemd-coredump captures a ~6 MB core per crash.
  • The MCP call ends with status host_unavailable → Tabularis app closed during approval — open it to approve writes.
  • The heartbeat file (tabularis.alive) stops updating ~2 s before the abort, then the MCP reports the host as gone.

Observed timeline for one attempt (local time):

time event
T+0.0s MCP run_query (write) arrives; approval enqueued
T+1.2s last heartbeat update written by the GUI
T+3.0s GUI aborts (SIGABRT, tokio panic)
T+16s MCP gives up: "app closed during approval"

Reproducible on demand: 4 aborts within ~1 hour, one per write-approval attempt, including after reinstalling the package. Read-only (SELECT) queries are unaffected.

Evidence from the core

  • Signal 6 (ABRT), si_code: SI_TKILL; crashing thread is a tokio-rt-worker.
  • Backtrace top frames (unstripped offsets, symbols unavailable):
    raise (libc) ← abort (libc) ← tabularis+0x13992ca ← tabularis+0x1373ef9 ← tabularis+0x139a6f9 ← tabularis+0xfa0a89 ← …
  • The main/UI thread was still inside the GTK/WebKit main loop at the moment of the dump.
  • Not resource exhaustion: ~62 GiB RAM, 0 swap used, no OOM-kill in the journal; not a hardware/segfault.

MCP subprocess output

[MCP] Sending: {"jsonrpc":"2.0","id":2,"error":{"code":-32000,"message":"Tabularis app closed during approval — open it to approve writes"}}

Possible cause (hypothesis)

The panic points at a nested block_on invoked from an async context. In the GUI there are several tauri::async_runtime::block_on(...) calls (src-tauri/src/lib.rs around lines 308 and 778, src-tauri/src/backup/mod.rs ~406) and Runtime::new().block_on(...) in src-tauri/src/ssh_tunnel.rs (~422, ~802). Without debug symbols I can't pin the exact one, but the panic fires while the GUI handles the MCP approval (queue → modal → preflight), so it is very likely in that path.

Impact

The built-in MCP server cannot be used for any write on Linux — every write approval aborts the app, which is the core MCP use case.

Happy to run additional diagnostics (e.g. a build with symbols / RUST_BACKTRACE=full capturing stderr) if useful.

Dominant language
TypeScript
Stars
5.1k
Forks
335
Avg merge
1d 12h
Merged PRs (30d)
287

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TabularisDB/tabularis

All issues in TabularisDB/tabularis

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.