diff --git a/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md b/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md
index afc69e72..baf114de 100644
--- a/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md
+++ b/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md
@@ -30,7 +30,9 @@ The root cause is unknown. It is NOT caused by zombie process accumulation (that
 
 **Ruled out:** Docker capability restrictions (cap_drop: ALL) — tested by temporarily removing all cap_drop/security_opt; crash still occurs.
 
-Remaining areas to investigate: changes to the agent runtime abstraction in story 343, or environment state left behind by the previous agent session.
+**Evidence of stale PTY fd:** After all agents stopped, storkit (PID 7) was still holding an open fd to `/dev/pts/ptmx` (fd 46). This is a leaked PTY master fd from a previous agent session. The reader thread spawned by `std::thread::spawn` in `pty.rs` is never joined, so the cloned reader fd stays open in the storkit process after the agent exits.
+
+Remaining areas to investigate: the unjoined reader thread leaking PTY fds, and whether the leaked fd from the first session interferes with the second PTY allocation.
 
 ## How to Reproduce