Provider agent process SIGKILLed mid-turn with no trace in T3 logs; request a typed record when the runtime terminates a session

Summary

A long-running claudeAgent provider agent process was killed with SIGKILL mid-turn (mid tool-command), while the T3 app and server kept running uninterrupted and macOS logged no intervention of its own. We could not find any trace of the termination or its trigger in T3's logs. If the runtime does terminate provider sessions (liveness window, resource guard, recycling), it would help external supervisors a lot if that showed up as a typed event or log record; if it does not, this may be a bug worth a look.

Environment

• T3 Code server 0.0.33 at the time of the incident (since updated to 0.0.34)
• macOS on an Apple Silicon Mac mini; local environment server on http://127.0.0.1:3773
• The affected thread: a long-running interactive Claude Code (claudeAgent) session with a large history (multi-day primary session), actively executing a Bash tool call at the moment of death

What happened

On 2026-08-26 at 02:22:37 local time (Europe/Amsterdam) the Claude agent child process of one thread died from a KILL signal, mid-command. The session's child processes died with it. No crash dialog, no crash report.

What we ruled out (all checked in the macOS unified log and process table)

• The machine: no reboot (last boot 00:26–00:27 that night, well before the incident), and the unified log contains no kernel memory-pressure, crash, or kill events in that minute.
• macOS resource enforcement at that moment: the only nearby system record is a resource-usage warning about T3 Code at 02:13 — 2.1 GB of disk writes in 1.8 hours, over the soft limit — nine minutes before the kill, and warnings of that type do not kill processes by themselves.
• Collateral damage: other concurrently running agent processes (other threads of the same environment) were demonstrably still alive at 02:42 and continued normally.
• The T3 app/server: both processes ran uninterrupted from 00:27 onwards, before, during, and after the incident.

So: exactly one agent process was SIGKILLed, everything around it stayed up, and the OS shows no initiative of its own. That points at the T3 runtime (or something it invokes) terminating that one provider session.

What we looked for in T3's logs

~/.t3/userdata/logs/server.trace.ndjson contains no record around 02:22:37 that explains or even mentions the termination. The thread itself remained intact; a later thread.turn.start resumed it fine (history preserved).

Ask

1. Does the server intentionally terminate provider agent processes under any condition (resource guard, recycling, idle/liveness policy, disk-write pressure)? If so, where would that be visible?
2. Feature request either way: when the runtime terminates a provider session, emit a typed event / trace record (and ideally a distinct session.status, e.g. error with a reason) so external clients and supervisors can distinguish "runtime terminated this session" from "the agent crashed". Right now the two are indistinguishable from the outside, which makes automated recovery decisions guesswork.

We can share more of our measured timeline (process table timestamps, unified-log queries used) if that helps.

Start by tracing the server's handling of claudeAgent provider processes and the session.status and thread.turn.start events, using ~/.t3/userdata/logs/server.trace.ndjson to compare behavior around the reported termination. Determine whether the runtime can terminate a provider session and, if so, document the relevant path; done means termination is distinguishable from an agent crash through a typed event or status reason.