1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
//! The path to run *this* program again.
//!
//! Every surface that drives `mecha <verb>` as a child process — the TUI
//! modals, detached releases, the trigger daemon, the Slack doctor — needs
//! its own binary's path. `std::env::current_exe()` looks like the answer
//! and carries a trap: on Linux it resolves `/proc/self/exe` to its target,
//! and after `cargo install` has replaced the file on disk, the target of a
//! *running* process reads `…/mecha (deleted)` — a path that does not exist.
//! Every child spawn then fails with `No such file or directory (os error
//! 2)`, in exactly the long-lived session an install is invisible to.
//!
//! Measured 2026-08-23, minutes after it shipped: a TUI nineteen minutes
//! older than the install had `/queues` fail by name, and an outbox release
//! fail *quietly* — the confirmation ran, the release child could never
//! start, and the item sat `pending` looking like the release surface was
//! broken. The update skill's `/proc/<pid>/exe … (deleted)` sweep already
//! documents the *diagnosis*; this module removes the failure.
//!
//! The fix is the same file that exposed the problem: `/proc/self/exe` is a
//! magic link, and **executing the link itself runs the deleted inode** —
//! the kernel resolves it to the file this process was launched from, on
//! disk or not. That is also the more coherent behaviour: a session drives
//! the version it *is*, rather than picking up a newer binary mid-session
//! whose flags may have moved (which is precisely what `/queues` against a
//! younger `mecha review` would have been, inverted).
use ;
/// The path to spawn this same program from.
///
/// On Linux, the `/proc/self/exe` link itself, so a replaced-on-disk binary
/// keeps re-execing the version it is. Anywhere else — or if `/proc` is not
/// mounted — whatever `current_exe` reports, which is the best available.