You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Bundled t3-resource-monitor ships mode 0644, so native process telemetry never starts on Linux/macOS #7736
On Linux, t3 serve (headless systemd user service, t3@0.0.33) logs:
Resource monitor binary at '.../node_modules/t3/dist/resource-monitor/linux-x64/t3-resource-monitor' is not executable.
Failed to read native resource telemetry history
The native process monitor never starts. The server itself is fine.
The file on disk is a valid ELF PIE (t3-resource-monitor 0.1.0, sysinfo), but npm extracted it as -rw-rw-r-- (0644 / 0664). T3's resolver then fails closed:
Same modes in t3@0.0.34-nightly.20260820.1146 (checked today). bin.mjs is executable because it is the npm bin entry; the Rust sidecars are copied into dist/resource-monitor/<platform>-<arch>/ without +x before npm pack.
Windows skips the mode check, so this specifically breaks Unix t3 serve / CLI installs. Desktop artifact builds that stage resources/resource-monitor/t3-resource-monitor separately may not hit it.
Related class of bug: #4924 (node-ptyspawn-helper also published 0644). This one is T3's own binary, not node-pty.
Workaround
find "$T3CODE_HOME/runtime/versions" -type f -name t3-resource-monitor -exec chmod +x {} +
# then restart t3 serve
Must be repeated after every runtime install/update, because a fresh extraction restores 0644.
Suggested fix
chmod +x the Unix sidecars when CLI release jobs copy them into apps/server/dist/resource-monitor/<platform>-<arch>/ (and assert mode in CI on the packed tarball).
What happened
On Linux,
t3 serve(headless systemd user service,t3@0.0.33) logs:The native process monitor never starts. The server itself is fine.
The file on disk is a valid ELF PIE (
t3-resource-monitor0.1.0,sysinfo), but npm extracted it as-rw-rw-r--(0644/0664). T3's resolver then fails closed:It does not
chmodthe sidecar.Root cause
This is in the published
t3tarball, not local umask or anoexecmount. Fromregistry.npmjs.org:Same modes in
t3@0.0.34-nightly.20260820.1146(checked today).bin.mjsis executable because it is the npmbinentry; the Rust sidecars are copied intodist/resource-monitor/<platform>-<arch>/without+xbeforenpm pack.Windows skips the mode check, so this specifically breaks Unix
t3 serve/ CLI installs. Desktop artifact builds that stageresources/resource-monitor/t3-resource-monitorseparately may not hit it.Related class of bug: #4924 (
node-ptyspawn-helperalso published0644). This one is T3's own binary, not node-pty.Workaround
Must be repeated after every runtime install/update, because a fresh extraction restores
0644.Suggested fix
chmod +xthe Unix sidecars when CLI release jobs copy them intoapps/server/dist/resource-monitor/<platform>-<arch>/(and assert mode in CI on the packed tarball).ResourceMonitorBinary.resolvefinds a non-executable Unix sidecar that T3 owns, chmod it (or spawn via an explicit interpreter) instead of stayingunavailable. Same idea as the startup chmod suggested on [Bug]: macOS agent terminals fail with 'posix_spawnp failed' - node-pty spawn-helper ships without exec bit #4924.Environment
t3@0.0.33via~/.t3/runtime/versions/0.0.33(t3 serve)0.0.34-nightly.20260820.1146