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
Harden the three rtk init call sites with < /dev/null #130
timeout 10 — a backstop that kills the hang after 10 seconds.
Closing stdin adds a third, and it is qualitatively better than (2) because it prevents the hang instead of terminating it. rtk's own gate is a TTY check; with stdin not a TTY, the prompt never appears.
Verified locally against rtk 0.48.0 — with stdin closed and no env var set, rtk init -g --hook-only --auto-patch completes in 8 ms against a fresh $HOME rather than prompting. The reason the env var was needed at all is that a devcontainer postCreateCommand is handed a pseudo-TTY, so rtk's is_terminal() check returns true and the prompt believes it's interactive. Redirecting stdin removes that condition directly.
Why it matters beyond belt-and-braces
Every call site swallows failure (|| true, 2>/dev/null || true). If timeout ever fires, rtk is left unconfigured silently. Making the hang unreachable is worth more than tuning the timeout value, because the timeout path has no observable signal.
Keep timeout as well — it still covers hangs that aren't stdin-related (e.g. a future network call, a lock).
Note
This is a behaviour change to the container startup path, so it wants its own verification: build claude-code and ralphex-fe, confirm the PreToolUse rtk hook claude entry lands in ~/.claude/settings.json in both, and confirm nothing regresses when ~/.claude is a pre-populated named volume.
Split out of #125, which measured this but kept the branch comment-only.
Proposal
Add
< /dev/nullto the threertk initinvocations:RTK_TELEMETRY_DISABLED=1 timeout 10 rtk init -g --hook-only --auto-patch < /dev/nullSites:
.devcontainer/init-plugins.shclaude-code/.devcontainer/init-plugins.shralphex-fe/init-docker.shWhy
The failure this guards against is the telemetry consent prompt blocking on stdin. Today we defend with two mechanisms:
RTK_TELEMETRY_DISABLED=1— the supported opt-out since rtk-ai/rtk#2477 (v0.44.0+). Documented in docs(rtk): record RTK_TELEMETRY_DISABLED as the supported opt-out (#117) #125.timeout 10— a backstop that kills the hang after 10 seconds.Closing stdin adds a third, and it is qualitatively better than (2) because it prevents the hang instead of terminating it. rtk's own gate is a TTY check; with stdin not a TTY, the prompt never appears.
Verified locally against rtk 0.48.0 — with stdin closed and no env var set,
rtk init -g --hook-only --auto-patchcompletes in 8 ms against a fresh$HOMErather than prompting. The reason the env var was needed at all is that a devcontainerpostCreateCommandis handed a pseudo-TTY, so rtk'sis_terminal()check returns true and the prompt believes it's interactive. Redirecting stdin removes that condition directly.Why it matters beyond belt-and-braces
Every call site swallows failure (
|| true,2>/dev/null || true). Iftimeoutever fires, rtk is left unconfigured silently. Making the hang unreachable is worth more than tuning the timeout value, because the timeout path has no observable signal.Keep
timeoutas well — it still covers hangs that aren't stdin-related (e.g. a future network call, a lock).Note
This is a behaviour change to the container startup path, so it wants its own verification: build
claude-codeandralphex-fe, confirm the PreToolUsertk hook claudeentry lands in~/.claude/settings.jsonin both, and confirm nothing regresses when~/.claudeis a pre-populated named volume.