Repository navigation
cmux NEXT Files: the row menu comes from the action registry (check-menu-actions red) - #23472
Conversation
…e list focused FileExplorerSectionView builds its right-click rows with an inline selector (check-menu-actions.py red since 56d4485). This test reads the row menu the section gives the table: every row must be a registry row (ActionRegistry.menuRun) in order, and Copy Path must be enabled and run while the list does not have the keyboard. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
…le the list is unfocused check-menu-actions.py has been red on feat-cmux-next since 56d4485: FileExplorerSectionView built its five right-click rows with an inline selector and hand-written titles, a second path beside the registry. A Files row now has its own ActionMenuContext (fileExplorerRow) with the five explorer actions placed in it (Open in cmux, Open With…, Reveal in Finder; then Copy Path, Copy Relative Path), and the section asks the registry for it. The context implies fileExplorerFocused, and a context menu item now carries its menu's implied facts (ActionMenuPayload.implied) into its validation and its run, so a row is enabled and runs while a terminal has the keyboard (right-clicking a row does not focus the list). Open With… without an app goes to the palette's argument step instead of failing with an empty app name. The unused fileExplorer.menu.openWith string is gone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
FileExplorerSectionView takes its row menu from the registry now. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
|
Owned by palette-audit on cosmic-gray · session |
|
Bead |
Base added New File, New Folder, Rename and Move to Trash rows and an Open With apps submenu to the Files row menu, each with an inline selector (check-menu-actions red again, plus FileExplorerOpenWithMenu.swift). The merge moves them onto the registry path: - fileExplorerNewFile, fileExplorerNewFolder, fileExplorerRename and fileExplorerMoveToTrash are catalog actions placed in fileExplorerRow (titles in ActionCatalog.xcstrings with base's 21 translations; the view's own strings are gone). New File and New Folder then edit the new item's name in its row, Rename edits the selection's, Cmd-Delete runs Move to Trash through the registry. The empty area shows only New File and New Folder. - Open With's apps submenu takes the registry's Open With row's place; each app row is a registry row (ActionRegistry.makeContextMenuItem) running fileExplorerOpenWith with app=<path> and the menu's fileExplorerFocused. Other... runs it with no app (now optional), and the handler lets the person pick one, then runs the action with it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
…them The bookmarks bar passes implied: .browserFocused to show Bookmark This Page. Since the row run took every implied fact, the row was enabled with a terminal focused and then refused (review of #23472). The merge keeps call-site facts to visibility; this pins both sides. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
NSMenu.update validates items only once NSApplication exists; without it every row read as disabled on the fleet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> # Conflicts: # Packages/macOS/CmuxNext/Sources/CmuxNextApp/FileExplorer/FileExplorerStrings.swift
…ripted Open With with no app is refused Review of #23472: the explorer handlers ran on the active window's tree, so Move to Trash from a back window's menu trashed the front window's selection; and Open With with no app opened the app chooser for a CLI run and reported success. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Passes: CI passes on CI passes on Written by red: cmux-next checks (god files, concurrency, crash safety, l10n); base red: the same failure on the base 2c92e44; does not block Tour of |
…ith with no app is refused The row menu's actions carry the id of the tree they were opened in (FileExplorerService.explorerArgument); the handlers run on that tree (its model, its window's undo stack, its rename field), else on the active window's. Before, Move to Trash, New File, New Folder, Rename and the copy and open rows from a back window's menu ran on the front window's selection. The Open With apps rows carry the same argument. Open With with no app asks for one only when the person ran it; a CLI or MCP run is refused (noSuchApp), and the chooser opens the file the panel was opened for rather than whatever is selected afterwards. The FileExplorer rows #23467 added to check-menu-actions-baseline.txt are gone (both files have no inline rows). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> # Conflicts: # Packages/macOS/CmuxNext/Sources/CmuxNextActions/ActionRegistry+ContextMenus.swift # Packages/macOS/CmuxNext/Sources/CmuxNextActions/ActionTarget.swift
|
Base merge c299e09 (feat-cmux-next 1a5b16b). Fleet step 4a1d09efe84a11501f8a77a7: 20 of 21 suites pass. The failure is ContextMenuShapeTests.menuTitlesUseOneToggleStyleAndNoPalettePrefixes on "Pin or Unpin Chat in Priority" (#23527's Priority row). It is a base finding: the same test fails the same way at base 1a5b16b (step 94b2e9f434eb21f55d5ba20c). Compile check: https://github.com/manaflow-ai/cmux/actions/runs/39638399348 (success). |
Takes the cmux-next-generated-patch artifact from run 39638411703 at c299e09, which lists the fileExplorerRow placements (and base's priorityRow ones) the merge left out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
…e-explorer-menu-actions
…e-explorer-menu-actions
|
Found 12 test failures on Blacksmith runners: Failures
...and 2 more test failures. View all on Blacksmith
|
Takes base's plans/cmux-next/action-surfaces.json and actions.md: GitHub merges them as text (the cmux-generated-v1 driver is local only), so every base regeneration conflicts. The PR or base autofix regenerates them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15bf1-fdc6-7623-8ee3-fa94b3900ccd&host=cosmic-gray
|
|
|
|
|
Landing at 7e68847 via ready-to-land: independent review SHIP (4fc7e20; delta at c299e09 and c62d36d; later commits are clean base merges), own |
|
Review (subagent, correctness first): SHIP at 7e68847 Delta review from the prior SHIP at c62d36d: three base merges (second parents adc8f45, 8a06461, 2c92e44, all on feat-cmux-next). Remerge-diff shows hand resolution only on the two generated files (base's side). PR diff outside generated files is unchanged (2575 lines added/removed, 23 files). ActionCatalog.xcstrings parses; keys = base at 2c92e44 plus the PR's 4 File Explorer keys, each entry matching its side. The 3 FileExplorer baseline rows stay removed. |
|
Shipped in:
|
…-hq; the repository keeps no merge guard (#23858) * cmux guards tests: a merge goes to the installed landing gate, and is refused when none is installed (red) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * cmux guards: a merge goes to the landing gate installed from cmuxterm-hq; the repository keeps no merge guard After hq#2830, #23472 still ran a merge_compile_guard.py copy without its gh-throttle fix: a guard here reaches a worktree only through a fetch or a base merge (deputy-2, 2026-10-21). Every rule it enforced is in the landing gate guards-sync installs from cmuxterm-hq main every 10 minutes (require-cmux-guards: the green Release compile on the exact head for a Swift change, its gh reads past the PATH guard's throttle, one bounded budget), so guards-from-base.sh defers to that gate when the account registers it, runs it when only its file is installed, and refuses the merge when it is missing, naming guards-sync and install.py. The update-branch warning still runs from origin/feat-cmux-next. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * cmux guards: an unregistered installed gate judges a merge whose launcher can't be read; the merge fetch uses gtimeout where timeout is missing From the Codex review of #23858: when origin/feat-cmux-next:scripts/ci/guards-from-base.sh could not be read, the settings hook warned and let the merge through without running an installed but unregistered landing gate, so its refusal was lost. And stock macOS has no timeout, so the merge-time fetch never ran there. tests/test_guard_hooks_from_base.py: the two new tests fail on the previous hook (2 errors of 24) and pass with this one (24/24). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-707fe4a5f156f632733f * cmux guards: GraphQL merges reach the gate; a registration counts only under a matcher that covers Bash From the second Codex review of #23858: - mergePullRequest and enablePullRequestAutoMerge (gh api graphql) count as merges in both the settings hook and guards-from-base.sh, so an installed but unregistered gate judges them. - guards-from-base.sh defers to a registration only when its PreToolUse matcher covers Bash. - With no launcher to read, the settings hook runs an installed gate whether or not it looks registered (at worst a second read), so its refusal is never lost. tests/test_guard_hooks_from_base.py: the new tests fail on the previous code (3 failures, 1 error of 27) and pass with this (27/27). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-707fe4a5f156f632733f * cmux guards: a registration is a command that runs the gate's file, not one that mentions it From the third Codex review of #23858: this repository's own settings hook names require-cmux-guards.sh in its fallback, so an account whose settings carried that hook read as registered and nothing judged the merge. A command counts only when one of its words (shlex) is the gate's file, as install.py writes it (bash '<hooks>/require-cmux-guards.sh'). The new test fails on the previous code (1 of 28) and passes with this (28/28). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-707fe4a5f156f632733f --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light-3x.png)
python3 scripts/cmux-next/check-menu-actions.pyhas been red on feat-cmux-next since 56d4485 (the right sidebar's Files section):The Files row's right-click menu built its rows with inline selectors and its own titles. The menu ran the explorer actions through a second path next to the registry. The inline path existed so the run got
fileExplorerFocused:ActionMenuTarget.performActionruns with the live key context, and right-clicking a row doesn't focus the list.The base merge (6820210) rewrote this fix for the rows base added after the PR opened. Base added New File, New Folder, Rename and Move to Trash, plus Open With as a submenu of the file's apps (56488d6, dd018d4). With them, the check reported 1 inline row in
FileExplorerSectionView.swiftand 2 in the newFileExplorerOpenWithMenu.swift. All of those rows now go through the registry too.Fix
Menu context. New
ActionMenuContext.fileExplorerRow; its implied context is.fileExplorerFocused.Placements. Rows in order:
The empty area shows only New File and New Folder.
New actions.
fileExplorerNewFile,fileExplorerNewFolder,fileExplorerRenameandfileExplorerMoveToTrashare catalog actions. They are CLI-exempt as live input, like the other explorer actions. Their titles are inActionCatalog.xcstrings, copied from base's 21-localefileExplorer.menu.*strings, which are removed. New File and New Folder then edit the new item's name in its row; Rename edits the selection's. Cmd-Delete runs Move to Trash through the registry.Open With apps submenu. The submenu replaces the registry's Open With row. Each app row is a registry row (new
ActionRegistry.makeContextMenuItem(for:in:arguments:title:)) that runsfileExplorerOpenWithwithapp=<path>. Other… runs it with no app; theappargument is now optional. The handler then shows the app chooser and runs the same action with the chosen app.How facts reach the run.
ActionMenuPayloadcarries the menu's own implied facts (ActionRegistry.impliedContext(for:)).ActionMenuTargetunions them with the live context into the invocation'skeyContextwhen it validates and runs an item. Facts a call site passes (makeContextMenu(implied:)) only show rows, as before. Otherwise the bookmarks bar, which passesimplied: .browserFocused, would enable Bookmark This Page while a terminal is focused, and the row would then refuse (from review).Each row acts on its own tree. The menu's rows carry the id of the tree they were opened in (
explorer,FileExplorerService.explorerArgument), and so do the Open With app rows. The handlers run on that tree: its model, its window's undo stack (Cmd-Z after Move to Trash) and its rename field. Before, every row ran on the active window's tree, so Move to Trash from a back window's menu trashed the front window's selection (review). A run with noexplorerargument still uses the active window's tree. That includescmux action run fileExplorerMoveToTrashand the other explorer ids, which run only while the explorer is focused (fileExplorerFocused).Open With with no app opens the chooser only for the person's own run. A CLI or MCP run is refused with
noSuchAppand shows nothing. The chooser opens the file it was shown for, not whatever is selected later.Baseline cleanup. The base merge 532b7ac brought in cmux-next guards: baseline the Files tree's inline menu rows (base red defaults-snapshot) #23467's baseline rows for
FileExplorerOpenWithMenu.swift(2) andFileExplorerSectionView.swift(1), with their comment. They are removed, since neither file has an inline row now.ExtensionsMenu.swift's stale row isn't this PR's and stays.Verification
Row menu test (red at base).
CmuxNextAppTests.FileExplorerTests/theRowMenuRunsTheRegistrysActionsWithoutTheListFocusedchecks, withfileExplorerFocusedremoved from the registry context:ActionRegistry.menuRun) in the order above, with Open With as the apps submenu;Its first version failed on the test commit 8572601 (fleet step
f1b5326f800fce6c6cab42dc:runs → [nil, nil, nil, nil, nil]).Open With test.
FileExplorerOpenWithTests/pickingAnAppRunsOpenWithWithThatAppThroughTheRegistry: an app row runsfileExplorerOpenWithwithapp=/Applications/Xcode.appandfileExplorerFocused. Other… runs it with no app.Bookmarks test (red at the old head).
CmuxNextActionsTests.ContextMenuImpliedFactsTestschecks two things. A menu's own facts enable and run its rows. A call site's facts don't: Bookmark This Page is disabled and doesn't run with no browser focused. It failed at the previous head 43217d1 plus this test (scratch branch, since deleted; fleet step030ccad3e8916ac6c1f084b2): Bookmark This Page enabled and ran.Two-window tests (red at the merge plus tests).
CmuxNextAppTests.FileExplorerWindowsTestscovers two windows with their own trees. New Folder from the back window's menu must make the folder in the back window's tree. An origin.cliOpen With with no app must be refused, with no open panel. Both failed at b99afcf, the base merge plus these tests (fleet step6950ad6e032efa02eb54725c:inBackfalse,refusedfalse).Green at head 4fc7e20. Fleet step
98f50ceb6adc062592d40c24: all 14 suites passed. That is the 12 above plus FileExplorerWindowsTests and base's new FileExplorerWatchTests.Compile check at head. https://github.com/manaflow-ai/cmux/actions/runs/39629481095 (success).
Green at head bbd0748. Fleet step
d9d1d4b4f0d32a16fa8623cb: all 12 suites passed (FileExplorerTests, FileExplorerFollowTests, FileExplorerOpenWithTests, FileExplorerEditTests, FileExplorerFocusRingTests, ContextMenuImpliedFactsTests, ContextMenuShapeTests, ActionSurfaceParityTests, ActionContractTests, ContextMenuEssentialsTests, BookmarkManagerMenuTests, RegistryReachabilityTests).Compile check at head.
fleet-compile-check.yml: https://github.com/manaflow-ai/cmux/actions/runs/39623177531 (success).Static checks.
check-menu-actions.pyexited 1 at the base (the line above) and reportsok: 38 inline menu rows in 29 baselined files, none newat head.check-group-menus.pyandprepush-gate.pyare ok.Observed / Not run
Observed: the fleet runs, the compile check and the static checks above.
Not run:
ActionSurfaceExportTests:plans/cmux-next/action-surfaces.jsonandactions.mdwere not regenerated by hand; the PR autofix regenerates them.Menu order changed from base: base had New File and New Folder first, then the open and copy rows, then Rename and Move to Trash. The order now follows the menu groups listed under Fix.
No capture: the rows are base's rows with base's titles. They come from the catalog now, so they have the actions' icons and the order and separators of the menu groups above. Base's order was New File and New Folder first, then the open and copy rows, then Rename and Move to Trash.
Changelog
Fixed: the Files section's right-click rows run while another view has the keyboard, and from the same actions as the palette and the CLI.
Agent session: cosmic-gray
🤖 Generated with Claude Code