Problem
unityctl wait controls how long it waits via its own --poll-timeout option (default 120s, WaitCommand.cs). But the global request-timeout option is aliased --timeout/-t (Program.cs), so this:
unityctl wait --timeout 300
parses successfully, looks like it sets a 5-minute wait, and then times out after 120s anyway:
Waiting for Unity Editor to be ready...
Timed out after 120s. Unity is not connected to the bridge.
--timeout is the obvious flag name for a command whose whole job is waiting, so this is the first thing both agents and humans reach for. Since the global option is valid on every command, there's no parse error and no warning — the mismatch between requested and effective duration is only discoverable by reading wait --help closely or noticing "after 120s" in the failure message.
Suggested fix
Pick whichever fits the CLI conventions best:
- Make
--timeout mean wait duration on wait — add a command-local --timeout option that shadows the global one and feeds the wait loop (keep --poll-timeout as an alias for compat). The global request timeout is meaningless for wait anyway: it polls cheap status endpoints in a loop.
- Or rename
--poll-timeout → --timeout outright on this command.
- At minimum, when
wait sees the global --timeout explicitly set, either honor it as the wait duration or print a warning: note: --timeout is the per-request timeout; use --poll-timeout to control how long to wait.
Option 1/2 matches user intent with zero learning curve; option 3 at least makes the footgun visible.
Related polish: the timeout message could echo which knob to turn, e.g. Timed out after 120s (default; use --timeout to wait longer).
Problem
unityctl waitcontrols how long it waits via its own--poll-timeoutoption (default 120s,WaitCommand.cs). But the global request-timeout option is aliased--timeout/-t(Program.cs), so this:parses successfully, looks like it sets a 5-minute wait, and then times out after 120s anyway:
--timeoutis the obvious flag name for a command whose whole job is waiting, so this is the first thing both agents and humans reach for. Since the global option is valid on every command, there's no parse error and no warning — the mismatch between requested and effective duration is only discoverable by readingwait --helpclosely or noticing "after 120s" in the failure message.Suggested fix
Pick whichever fits the CLI conventions best:
--timeoutmean wait duration onwait— add a command-local--timeoutoption that shadows the global one and feeds the wait loop (keep--poll-timeoutas an alias for compat). The global request timeout is meaningless forwaitanyway: it polls cheap status endpoints in a loop.--poll-timeout→--timeoutoutright on this command.waitsees the global--timeoutexplicitly set, either honor it as the wait duration or print a warning:note: --timeout is the per-request timeout; use --poll-timeout to control how long to wait.Option 1/2 matches user intent with zero learning curve; option 3 at least makes the footgun visible.
Related polish: the timeout message could echo which knob to turn, e.g.
Timed out after 120s (default; use --timeout to wait longer).