Repository navigation
fix(desktop): run an agent command on tmux that cannot tag its pane, untracked - #8705
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
|
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
All reported issues were addressed across 5 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Turn on auto-fix | Re-trigger cubic
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
…untracked Agent `run` inside tmux tagged its pane with a pane option (`set-option -p`, tmux 3.0+) and refused the command when that failed, so on older tmux every agent run failed, with the background executor off too. A run whose pane cannot be tagged now goes ahead untracked: Stop, sign-out and switching Terminal off leave it alone, since nothing could tell its pane from one of the user's. Tagged runs are unchanged. The gate still holds every command until the tagging call has finished.
…unning, and reap it once its pane is gone
…ap and close finished untracked panes - Only tmux before 3.0, which refuses `set-option -p` as an unknown flag or invalid option, runs a command untracked. A tmux that can tag panes but did not (it timed out, or failed otherwise) gets the run refused, as before, so no command starts that Stop and sign-out could never end. - tmux 3.x answers `display-message` for a pane that is gone with an empty line rather than an error, so an untracked run's pane is gone unless tmux echoes its id back. - A finished untracked run's pane is closed, and a run that finishes after its call returned has its pane closed when it is reaped, so dead panes kept by `remain-on-exit` do not pile up.
…rt command proves it is the run's
…, and use a separator no field can straddle - Real tmux 2.9a refuses `set-option -p` with its own getopt's `unknown option -- p` and set-option's usage line (BSD getopt on macOS: `illegal option -- p`). The untracked fallback only matched later wordings, so on real pre-3.0 tmux every run was refused. The fake tmux and the tests now use the text captured from real 2.9a. - The `-F` separator `|~sim~|` began and ended with the same character, so a field ending in `|~sim~` was misread rather than dropped. `<~sim~>` has no proper prefix that is also a suffix, so it is only found where it was written or wholly inside a field, whose line is then dropped.
07697ce to
8dddbd7
Compare
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Summary
Follow-up to #8668. To stop only its own commands, an agent
runinside tmux tags its pane with a pane option (set-option -p). Pane options need tmux 3.0 or later. #8668 refused the command whenever tagging failed, so on older tmux every agent run failed, even with the background executor off.set-option -p, and Sim recognises the refusal from the text real tmux 2.9a prints: its getopt'sunknown option -- p, orillegal option -- pwith BSD getopt on macOS, followed by set-option's usage line. A tmux that can tag panes but did not (it timed out, or failed otherwise) still gets the run refused, so no command starts that Stop and sign-out could never end.runningrather than completed, and keeps its files.#{pane_id}, a format every tmux knows; tmux 3.x answers for a missing pane with an empty line rather than an error. It is not kept as an orphan when its Sim terminal closes.remain-on-exitdo not pile up. An untracked run's pane is closed only when tmux reports its start command (#{pane_start_command}, which old tmux has too) as the run's own script, so a user's pane that took the id after a tmux restart is never closed.The
panefield in a run result#8668 changed a run result's
panefrom the run's window id (@N) to its pane id (%N). I checked every consumer:paneargument ofread,input,killorclose. All four hand it to tmux as-t, and tmux accepts a pane id there. A pane id is also more precise than a window id:@Nmeant whichever pane of that window was active, so a split could redirect the call.paneargument as asession:window.panetarget frompanes; a run's pane id is still a valid target, so nothing there breaks.Format separator follow-up to #8720
-Fseparator changes from|~sim~|to<~sim~>.|~sim~|began and ended with the same character, so a field ending in|~sim~(a cwd or a window name) was misread rather than dropped.<~sim~>has no proper prefix that is also a suffix. It can only be found where Sim wrote it, or wholly inside a field, and that changes the line's field count, so the line is dropped.Tests
|~sim~|.listPanesparses on both.tmux.ts, the first two tests fail.