[Bug]: Bundled t3-resource-monitor ships mode 0644, so native process telemetry never starts on Linux/macOS #7736

What happened

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:

// ResourceMonitorBinary.resolve, non-Windows
if ((stat.mode & 73) === 0) // 0o111
  fail ResourceMonitorBinaryNotExecutable

It does not chmod the sidecar.

Root cause

This is in the published t3 tarball, not local umask or a noexec mount. From registry.npmjs.org:

t3@0.0.33
  0644  package/dist/resource-monitor/darwin-arm64/t3-resource-monitor
  0644  package/dist/resource-monitor/darwin-x64/t3-resource-monitor
  0644  package/dist/resource-monitor/linux-x64/t3-resource-monitor
  0644  package/dist/resource-monitor/win32-x64/t3-resource-monitor.exe
  0755  package/dist/bin.mjs

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-pty spawn-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

1. 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).
2. Defensive: if ResourceMonitorBinary.resolve finds a non-executable Unix sidecar that T3 owns, chmod it (or spawn via an explicit interpreter) instead of staying unavailable. 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

• Linux x86_64 (glibc), Node v22.23.2
• t3@0.0.33 via ~/.t3/runtime/versions/0.0.33 (t3 serve)
• Also verified the tarball modes for 0.0.34-nightly.20260820.1146