[Bug]: When systemd-run fails, the cause is discarded and every Claude turn shows only "Provider turn failed." #26382

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run t3 serve on Linux with the Claude provider, where agent scopes are on (systemd user manager available).
2. Fill $XDG_RUNTIME_DIR (/run/user/<uid>) to 100%. In my case the Omarchy shell's Quickshell log filled it (DST clock step (Oct 25, 03:00 CEST → 02:00 CET) starts a 1ms QTimer warning storm in the shell: 4.5M log lines fill /run/user tmpfs, wayland-wm-app-daemon crash-loops, all uwsm app launches fail with "Invalid arguments" omacom/omarchy#16677). Simple repro: fill the tmpfs with a large file.
3. Send a message on a thread whose Claude process has been closed, so T3 has to start a new one.

Expected behavior

The thread's error names the launch failure, e.g. "Could not start Claude: systemd-run failed: Unit ... not found", and ideally hints that the runtime dir is full. Alternatively, T3 falls back to launching without a scope, as it already does when no systemd user manager is detected.

Actual behavior

Every turn fails about 100 ms after it starts with only Provider error: Provider turn failed. (failure.class: transport_error, code: null), from every client (macOS and Android via T3 Connect).

systemd-run --user --scope ... fails before Claude starts, because systemd cannot write the transient unit file under /run/user/<uid>/systemd/transient. T3 discards its stderr. Nothing about it appears in server.trace.ndjson, the provider event log or boot-service.log. The only hint is a misleading orchestration-v2.claude-mcp-servers-unavailable warning for t3-code, which happens because setMcpServers is called on a process that never started.

The standalone CLI (claude -p) and a manual cold --resume of the same session both work, which made this hard to diagnose. I had to rerun T3's systemd-run wrapper by hand to see the error.

Related: #26082 (another case where the real cause is hidden behind "Provider turn failed").

Impact

Blocks work completely

Version or commit

0.1.3-nightly.20261027.3754

Environment

• t3 serve (run directly, not via the t3code.service unit) - Claude Code CLI 2.1.301 - Arch Linux (Omarchy 4.0.4), systemd 261.2 - Clients: macOS and Android via T3 Connect

Logs or stack traces

The turn failure as stored in statev2.sqlite:


{"type":"error","status":"failed","title":"Provider error","failure":{"class":"transport_error","message":"Provider turn failed.","code":null,"retryable":null}}


The only warning in server.trace.ndjson:


orchestration-v2.claude-mcp-servers-unavailable {"threadId":"32636a13-...","servers":["t3-code"]}


The real error, seen only by rerunning the wrapper by hand:


$ systemd-run --user --scope --quiet --collect --slice=app-t3code-agents-<id>.slice -- true
Failed to start transient scope unit: Unit run-p402236-i4601228.scope not found.

$ df -h /run/user/1000
tmpfs  1.5G  1.5G  0  100% /run/user/1000

Screenshots, recordings, or supporting files

No response

Workaround

Free space in /run/user/<uid>. In my case: truncate -s0 /run/user/1000/quickshell/by-id/*/log.* (Omarchy's shell log, see omacom/omarchy#16677). systemd-run worked immediately, with no T3 restart.