Repository navigation
uc machine init requires a TTY in non-interactive shells (could not open TTY) #386
Description
Uncloud version: uc version 0.19.0
Problem
uc machine init cannot run in a non-interactive shell (CI, automation, a piped/backgrounded process) because its progress UI needs a TTY. Even with -y/--yes set, it fails:
$ uc machine init root@<ip> --no-dns -y # run without a controlling TTY
Error: wait for cluster to be ready: bubbletea: error opening TTY: bubbletea: could not open TTY: open /dev/tty: device not configured
The -y/--yes help text says it "should be explicitly set when running non-interactively, e.g., in CI/CD pipelines", which implies non-interactive use is supported — but -y only auto-confirms prompts; the bubbletea progress view still requires /dev/tty. uc ctx (e.g. uc ctx rm) has the same TTY requirement.
Steps to reproduce
- From a process with no controlling terminal (CI runner,
nohup, a script whose output is piped), run:
uc machine init root@<server-ip> --no-dns -y - It errors with
could not open TTYinstead of completing.
Workaround
Allocating a pseudo-TTY works — the cluster is actually created fine; only the progress spinner needs the TTY:
script -q /dev/null uc machine init root@<server-ip> --no-dns -y
Request
A non-interactive / plain-output mode for uc machine init (and uc ctx): detect the absence of a TTY and fall back to plain line-by-line log output (or add a --no-tui/--plain flag). That would let Uncloud be driven from CI and IaC tooling without a PTY hack.
Context
Hit while automating Uncloud-on-Hetzner provisioning with mise + OpenTofu: https://github.com/joeblew999/vm-uncloud
Activity
joeblew999 commentedon Jun 3, 2026
Verified still present on the latest nightly build (2026-06-02), not just v0.19.0:
uc machine initanduc ctxexpose only-y/--yes— no--no-tui/--plain/non-interactive flag — and still require/dev/ttyfor the progress UI. So this is current, not fixed.miekg commentedon Jun 3, 2026
related: #286
miekg commentedon Jun 3, 2026
curious (and you seem to be in a position where you can easily test), what does
uc machine init root@<ip> --no-dns -y | catdo?joeblew999 commentedon Jun 6, 2026
Hit this on
uc0.19.0 (macOS client → single Hetzner Cloud node) in a non-interactive shell:One detail that might help: the failure is only the readiness spinner. By the time it errors, the cluster is already functional —
uc context lsshows it, machine registered),uc machine lsreports the machineUp.So recovery is just to skip the rest of
initand run the remaining (headless-safe) steps by hand (uc machine ls, thenuc deploy …). A--no-tui/CI=1/ no-TTY path that polls for readiness without bubbletea would makeuc machine initcomplete in CI/automation. (-yalone doesn't avoid it.)joeblew999 commentedon Jun 6, 2026
Thanks @miekg. Fair question — I've since torn this cluster down to keep the account at €0, so I can't re-run it live this second, but I can confirm the exact variant on my next provision and post the output.
Reasoning in the meantime, from the error itself (
open /dev/tty: device not configured):uc/bubbletea is opening /dev/tty — the process's controlling terminal — directly for the readiness spinner, rather than gating onisatty(stdout). So… --no-dns -y | catonly redirects stdout;/dev/ttyis still unopenable in a shell with no controlling terminal (CI,nohup, a non-interactive agent shell), so I'd expect it to fail identically. Happy to be proven wrong by the actual run.What does sidestep it is handing the process a PTY rather than redirecting stdout — e.g. on macOS/BSD
script -q /dev/null uc machine init root@<ip> --no-dns -y(Linux:script -qec '…' /dev/null). That's the workaround I reached for.I'll run
| catvsscriptside by side next time I bring a node up and report the outputs here. If a--plain/--no-tuipath that polls for readiness without bubbletea is on the table, that'd be the clean fix for CI/automation.joeblew999 commentedon Jun 6, 2026
Tested it.
uc0.19.0, fresh Hetzner Cloud node, non-interactive shell with no controlling terminal (the CI/agent case).uc machine init root@<ip> --no-dns -y | cat→ install + cluster init complete, then:So
| catdoes not help — it only redirects stdout; the readiness spinner opens/dev/tty(the controlling terminal) directly, which doesn't exist here, so it fails the same way. Note the cluster is fully initialised before the spinner errors — only the wait UI dies.script -q /dev/null uc machine init root@<ip> --no-dns -y(give it a PTY instead of redirecting) →So a PTY fixes it; redirecting stdout doesn't. The clean fix would be to fall back to a plain/non-TUI renderer (or a
--plain/--no-tuiflag) that polls for readiness when/dev/ttyisn't available, souc machine initcompletes in CI/automation withoutscript.fix(up): PTY-wrap uc machine init/add so mise run up works headlessly
psviderski commentedon Jun 17, 2026
@joeblew999 What actual environment do you run it so you get this error? I can't reproduce in my environments without a tty which bubbletea handles correctly.
I'd appreciate if you can give a human response instead of this AI BS.
cli: do not use interactive TUI elements when control terminal (tty) …