[arjun28115]

Plugin file pickers now use the active Frame or Dialog as their owner on macOS and the active window as the Swing parent on other platforms. The shared native-dialog helper states the directory mode before showing, restores the prior property value through nested dialogs and failures, and disposes the native peer in finally. This addresses the source-established defects in #551; the reported Fluck Agent Attach-button symptom still needs native UI reproduction.

The browser's existing picker implementation now shares that helper. Plugin save pickers also install the supplied extension filter. Native SAVE-panel filtering remains platform behavior to check manually; this does not promise enforcement of an output filename extension.

Contributor provenance:

• @arjun28115 authored fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: shared owner/helper extraction, explicit directory mode, finally disposal, diagnostics, and seven helper tests.
• @JaspreetSingh33 independently authored fix: attach plugin file picker to active window #611: Frame/Dialog ownership, Swing parent selection, native disposal and the macOS save-filter addition. Ownership and disposal are covered by fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552's implementation; the save-filter addition is preserved in commit e8f3bf1, which carries Jaspreet's co-author credit.
• Review-agent work: comparison and integration of fix: attach plugin file picker to active window #611, removal of dangling obsolete helper comments, and validation. These are not original contributor achievements.

Validation: the original #552 head 8918bbb passed all nine hosted checks, including all platform builds and ktlint/detekt. Current-head browser-package tests and root ktlintCheck/detekt are queued behind the shared local build lock; current-head CI and Claude review are pending. No native UI verification is claimed.

Manual checks still required: use Fluck Agent Attach file with a hardware-accelerated browser surface; test Open and Save from both a main window and an existing modal; cancel and select a file; open a plugin file picker during a browser folder panel and confirm file mode and restored folder mode; verify native peers are released after repeated picks. Other host picker entry points are outside this change.

Current-head review — 2026-09-14

Current head e6cc0b05e823f21a3b741416f18f59270f1f15ed has all ten hosted checks passing, including macOS/Linux/Windows builds, root ktlint/detekt and compatibility. Downloaded the macOS test artifact and verified 11 FilePickerDeliveryTest, 8 OwnedFileDialogTest and 11 NativeFileDialogsTest tests with zero failures/errors/skips. These are current-head executed tests, superseding the prior pending-validation handoff. Fresh main includes merged #626; the relevant implementation is not already present in main/dev. No native UI execution is claimed.

@arjun28115’s subsequent contributor repairs now provide once-only callback delivery and normalize dotted/blank extensions, with 11 tests. Prior agent fixture repair and @JaspreetSingh33’s #611 save-filter integration remain preserved with explicit credit. This sweep made no production-code changes.

Tests exercise helper behavior; they do not prove provider call-site wiring, native owner selection or peer disposal. The comment claiming that reverting call sites necessarily causes a compile error overstates coverage. Current wiring was reviewed directly. Fluck Attach reproduction and native Frame/Dialog Open/Save, cancellation, nested directory-mode and repeated peer-disposal checks remain manual follow-up. Remaining pre-existing directory-flag writers are outside this fix. #611 stays closed and fully represented here; no other PR was modified.

Current-head Claude review completed: https://github.com/risa-labs-inc/BossConsole/actions/runs/34804614330. It confirms both substantive repairs and fixture regression. MIME/glob support is outside the documented extension-only plugin API; browser HTML accept has different semantics. Callback-failure log wording, import/KDoc tidy and broader owner/wrapper tests are nonblocking follow-ups, with detailed evidence in the final review comment.

Remaining unrouted native sites: components/plugin/providers/DesktopDirectoryPickerProviderImpl.kt and platform/DesktopFilePicker.kt write the directory flag without finally restoration (resetting to false); platform/FilePicker.kt and components/settings/shared/SettingsComponents.kt retain separate dialogs. These pre-existing sites are not fixed by this PR.

[kshivang]

@claude Please review the current head of this PR against dev for correctness and meaningful regression coverage. Check plugin-context wrapper routing for #548; for #552 check native owner selection, nested directory mode restoration and native-peer disposal. Related #611 is being compared for consolidation by this group; please do not mutate other PRs.

[claude]

Claude finished @kshivang's task in 6m 50s —— View job

---

Review: #552 head vs origin/dev

• Read the PR diff against dev
• fix(plugins): scope PluginStorageFactory.createStorage to the calling plugin's own id #548: plugin-context wrapper routing for the file picker
• fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: native owner selection
• fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: nested directory-mode restoration
• fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: native-peer disposal
• Regression coverage assessment

The extraction is the right call and the withDirectoryMode split is the best thing in the diff — the property discipline is the part that is easy to get wrong, and pulling it away from the display requirement is what made it testable at all. showModal's restructure is also strictly better than what it replaced: the old version restored and disposed in the same finally, so a throwing System.setProperty skipped dispose(); the new nesting can't.

Below, the things I'd want addressed before this lands, in priority order.

---

1. The consolidation stopped one file short, and it's the one that produces the sticky bad state — DesktopDirectoryPickerProviderImpl.kt:36-63

composeApp/src/desktopMain/kotlin/ai/rever/boss/components/plugin/providers/DesktopDirectoryPickerProviderImpl.kt sits in the same package as the file this PR fixes, is also plugin-facing (PluginContext.directoryPickerProvider), and is not listed as out of scope in the description. It is a hand-rolled fourth copy with five defects, four of which this PR's own helper fixes for free:

System.setProperty("apple.awt.fileDialogForDirectories", "true")
val owner = KeyboardFocusManager.getCurrentKeyboardFocusManager().activeWindow as? Frame
val dialog = FileDialog(owner, "Select Project Directory", FileDialog.LOAD)
dialog.isAlwaysOnTop = true
dialog.isVisible = true
val directory = dialog.directory
val file = dialog.file
System.setProperty("apple.awt.fileDialogForDirectories", "false")   // unconditional, no finally

• The restore is not in a finally. If isVisible = true throws, the flag is left "true" for the life of the process. Every later FileDialog in the tree that does not state its own mode — platform/FilePicker.kt:41, SettingsComponents.kt:875 — then opens as a directory chooser. That is The plugin file picker opens an ownerless AWT FileDialog, so a plugin's file-pick can go nowhere #551's symptom class reproducible with no plugin involved at all.
• It writes "false" rather than restoring. This is the exact thing OwnedFileDialogTest pins ("an absent property is cleared afterwards, not written back as false"). One directory pick permanently defeats it, and every subsequent withDirectoryMode(false) restore then writes "false" back instead of clearing. The reader is fixed; the writer that breaks the invariant is not.
• as? Frame drops a Dialog owner — precisely the case OwnedFileDialog.kt:16-18 says matters most, and the case NativeFileDialogs.kt:291-297 still calls out by name: "Same fix as DirectoryPickerProviderImpl, except that one only handles a Frame owner." The PR leaves that comment pointing at an unfixed file.
• No dispose() — native peer leaked, which is the disposal question directly.
• No try/catch at all. A throw escapes the invokeLater body and onResult is never called, so the plugin waits forever with no cancel. (NativeFileDialogs.answerOnce exists for exactly this.)

ownedFileDialog("Select Project Directory", FileDialog.LOAD) + showModal(directories = true) collapses items 1-4 to six lines. Fix this →

platform/DesktopFilePicker.kt:43-51 has the same unguarded true→false write. That one is declared out of scope, but the description characterises it as "creates a LOAD dialog without touching the flag," which is the opposite of what it does — it is a writer, and the same fix applies.

2. onResult is called inside the try, so a throwing callback produces a second onResult(null) — FilePickerProviderFactory.kt:56-60, 93, 118-122, 155

if (dir != null && file != null) {
    onResult("$dir$file")      // if the plugin's callback throws...
    ...
} catch (e: Exception) {
    logger.error(...)
    onResult(null)             // ...the plugin also gets a cancel
}

The plugin receives a path and a null for one pick, and the log says "File picker failed" for a pick that succeeded. This is pre-existing, but the diff touched both catch blocks and reasoned explicitly about "onResult(null) is the only channel this API has" — so it's the right moment. NativeFileDialogs.answerOnce is the existing answer to this shape; at minimum hoist the result out of the try and dispatch once after it.

3. A leading dot in a filter greys out every file — FilePickerProviderFactory.kt:49-51, 111-113, 67-75, 132-140

filters.any { ext -> name.endsWith(".$ext", ignoreCase = true) }

A plugin passing ".csv" (entirely plausible — the accept attribute spells it that way, and nothing in the API docs says otherwise) yields endsWith("..csv"), which matches nothing, so the panel disables every file and the pick looks broken. Same on the JFileChooser branch: FileNameExtensionFilter compares against the bare extension, so ".csv" never matches either.

fileDialogSuffixes() in NativeFileDialogs.kt:376 exists precisely to normalise this (removePrefix(".")), plus the all-or-nothing MIME-token rule, and matchesSuffix()/narrowTo() are internal in the same module. Commit 2 propagated the unnormalised copy to the SAVE path, so there are now three hand-rolled copies of suffix matching in a PR whose thesis is that these two files must not drift. Folding filter construction into the helper alongside creation would be the consistent finish.

4. pickSaveFile skips the sanitisation the browser path has — FilePickerProviderFactory.kt:107-109

if (suggestedFileName != null) { dialog.file = suggestedFileName }

NativeFileDialogs.showSave does dialog.file = safePrefill(suggestedFileName), and safePrefill's KDoc (NativeFileDialogs.kt:326-341) states why: only the last segment survives, "so a suggestion of ../../x cannot steer where the panel opens", and control characters are dropped. Here the suggestion comes from a plugin and is passed through raw. A plugin passing "reports/2026/summary.csv" puts a slash in NSSavePanel's name field; "../x" is worse. safePrefill is internal in the same module — one call.

5. A non-Frame, non-Dialog active window falls back to no owner — OwnedFileDialog.kt:36-40

when (val active = activeDialogOwner()) {
    is Frame -> ...
    is Dialog -> ...
    else -> FileDialog(null as Frame?, title, mode)   // a plain Window lands here
}

activeWindow can be a Window/JWindow — a heavyweight popup or tooltip layer — and that lands in the ownerless branch this PR exists to remove, in a case where a perfectly good owner is one hop up the chain. Walking it fixes both consumers at once, JFileChooser's parent included:

internal fun activeDialogOwner(): Window? =
    generateSequence(KeyboardFocusManager.getCurrentKeyboardFocusManager().activeWindow) { it.owner }
        .firstOrNull { it is Frame || it is Dialog }

Worth one manual check while you're in here: in the nested case the owner resolves to the still-showing outer FileDialog, where it used to be null. Legal in AWT and almost certainly what you want, but it is a behaviour change on the one path you can't reproduce.

6. The test's own teardown clears the value it just restored — OwnedFileDialogTest.kt:36-37

original?.let { System.setProperty(MAC_DIRECTORY_MODE, it) }
    ?: System.clearProperty(MAC_DIRECTORY_MODE)

System.setProperty returns the previous value, and capture() cleared the property on line 31 — so the let evaluates to null, the elvis fires, and the property is cleared immediately after being restored. A JVM that started with the flag set has it silently unset for every test that runs after this class. The restorer's own test gets the restore wrong, which is a nice illustration of why the helper was worth extracting:

val value = original
if (value == null) System.clearProperty(MAC_DIRECTORY_MODE) else System.setProperty(MAC_DIRECTORY_MODE, value)

7. Smaller things

• The lost record. The deleted showModal KDoc named the three files still creating an unrouted LOAD dialog. The new KDoc (OwnedFileDialog.kt:27-29) says only that NativeFileDialogs "recorded that every other FileDialog in the tree should be routed through the same helper" — so the list of what is left is gone, and it was the only place it existed. Given how much this repo leans on that kind of in-tree record, please name the four remaining sites (platform/FilePicker.kt:41,99, platform/DesktopFilePicker.kt:45, SettingsComponents.kt:875, and DesktopDirectoryPickerProviderImpl.kt:48 if it isn't fixed) and flag which of them write the flag.
• Package placement. A cross-cutting AWT helper living in ai.rever.boss.plugin.browser already reads oddly from components.plugin.providers; when SettingsComponents and platform/FilePicker follow, settings code will be importing from plugin.browser. ai.rever.boss.platform or a utils.awt would age better, and moving it is free right now.
• Result assembly wasn't unified. "$dir$file" (lines 57, 119) depends on macOS returning getDirectory() with a trailing separator, which FileDialog does not document. NativeFileDialogs uses File(directory, name) throughout. It works today; File(dir, file).absolutePath removes the dependency.
• SAVE-mode filter. Safe — the macOS peer answers yes for anything that isn't a regular file, so directories stay navigable (narrowTo's KDoc) — and consistent with showSave. But note showSave pairs the filter with pathWithExtension; here nothing appends, so the plugin can still get back a path outside the filter list it supplied.
• MAC_DIRECTORY_MODE declared at line 94, after all three of its uses. Legal, but it reads backwards.

---

#548: plugin-context wrapper routing

Routing is complete for both pickers — all three wrappers forward:

Provider	DefaultPlugin	TrackingPluginContext	SandboxedPluginContext
filePickerProvider	:868	:406	:240
directoryPickerProvider	:893	:411	:247

So nothing is broken, but nothing pins it either, and this exact regression has shipped: docs/release-notes/v9.2.35.md:22-23 records directoryPickerProvider and projectDataProvider falling through to the interface default null in both wrappers, so "Open Project" and Evolve's "Browse" silently did nothing. AGENTS.md records the same failure for mcpToolRegistry, and states the three-wrapper rule as a rule — with no test behind it. TrackingPluginContextMcpTest is the only wrapper test and covers MCP registration, not forwarding.

A reflection test is ~15 lines and is the highest-value missing test in this area: enumerate PluginContext's provider vals and assert each is declared as an override in TrackingPluginContext and SandboxedPluginContext. Today a new provider silently returns null for every tracked and every sandboxed plugin, which is the shape of bug that reaches users as "the button does nothing." Out of scope for this PR, but it belongs to whichever of #548/#552/#611 the group consolidates into.

Regression coverage for #552

What's covered is good and correctly chosen: six focused tests on withDirectoryMode, including the two cases that are actually subtle (absent-stays-absent, reverse unwinding) and a throwing body. Modulo finding 6, they'd catch a regression in the restore logic.

What is not covered, in descending value:

1. Nothing fails if someone writes FileDialog(null as Frame?, ...) again — which is the defect this PR exists to fix. The repo already pins this kind of invariant against source (OsOpenArgumentsTest pins the CLI subcommand list, FileTypeCategoriesTest pins two extension sets, and NativeFileDialogsTest exists specifically to catch a dropped registration line). A test that scans composeApp/src/desktopMain for FileDialog( outside OwnedFileDialog.kt against a shrinking allowlist would give the fix real teeth — and would have surfaced findings 1 and 7 on its own.
2. The owner branches are untested. Deleting is Dialog -> from ownedFileDialog fails nothing, even though "the active window is a Dialog whenever a BOSS modal is up" is the stated motivation. Extracting internal fun fileDialogOwner(active: Window?): Window? — pure, taking the window rather than reading the focus manager — makes the classification testable, and makes finding 5 checkable too. AGENTS.md's mutation-verification standard for pluginSectionAbsence is the bar here.
3. showModal's dispose-in-finally is untested and can't be from a headless JVM as written, since FileDialog's constructor throws HeadlessException. Fine to leave — but say so in the KDoc rather than letting the reader assume the "each of which has a test" claim covers showModal too. It covers withDirectoryMode only.

Disposal summary

Site	Owner	States mode	Disposes
NativeFileDialogs	yes	yes	yes
FilePickerProviderFactory (mac)	fixed here	fixed here	fixed here
FilePickerProviderFactory (JFileChooser)	fixed here	n/a	yes (internal to showDialog)
DesktopDirectoryPickerProviderImpl	Frame only	writes, never restores	no
platform/DesktopFilePicker	no	writes, never restores	no
platform/FilePicker ×2	no	no	no
SettingsComponents	no	no	no

On #611 and consolidation

Commit 2 (e8f3bf1, "preserve save filters from PR 611") already pulls #611's macOS SAVE-mode filter into FilePickerProviderFactory.kt:110-113, so if both land, #611 is either a no-op or a conflict on those exact lines — the group should pick one carrier. Note the non-mac branch already had save filters, so #611's contribution here is mac-only parity, and it inherits finding 3. I have not touched #611 or any other PR.

What I could not verify

./gradlew is not runnable in this environment (command approval denied), so I could not execute OwnedFileDialogTest, ktlintCheck or detekt myself — I'm taking the PR's report of those at face value. Everything above is from reading the tree. Findings 1, 3, 4 and 6 are static and don't need a display; findings 2 and 5 are reachable by inspection but their user-visible consequence would want the manual check the description already flags as outstanding.
· branch fix/plugin-file-picker-owner

[kshivang]

@arjun28115 Bounded review handoff for #552, which now carries @JaspreetSingh33's #611 contribution. I preserved the validated original implementation and pushed two review commits: e8f3bf1 integrates Jaspreet's macOS save filter with co-author credit and removes stale extraction comments; the latest follow-up fixes OwnedFileDialogTest.restore, where System.setProperty's nullable return triggered the Elvis clear immediately after restoration, and adds a fixture regression. That fixture defect was in the original #552 submission; the fixes are agent work.

Remaining substantive issues and required validation:

1. Shared-dev defect in the touched provider, not introduced by your ownership fix: FilePickerProviderFactory invokes onResult(path) inside its try. If plugin callback code throws, catch logs a picker failure and calls onResult(null) again. Move result delivery outside the picker-operation catch or use a once-only delivery boundary. Test successful selection plus throwing callback and assert exactly one callback; test picker failure yields one null. Both Open and Save have this shape.
2. Existing Open/Swing filter behavior propagated to Save by the agent's fix: attach plugin file picker to active window #611 integration: an extension such as .csv is matched as ..csv, disabling valid choices. Normalize a leading dot consistently, or establish and enforce an explicit bare-extension contract, with tests for csv/.csv, mixed case, and an empty filter list. The newly copied Save path is integration work, not an original fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552 defect. Do not promise that a native SAVE filter forces the final typed output extension.
3. Validation/infrastructure, not author failure: original 8918bbb had nine green hosted checks. Current-head browser tests plus root ktlintCheck/detekt have not started because of the shared build queue; current hosted CI is still pending. Native Fluck Agent Attach, Frame/Dialog owner, cancellation, and nested folder/file checks remain unperformed. The body correctly says Addresses The plugin file picker opens an ownerless AWT FileDialog, so a plugin's file-pick can go nowhere #551 because ownership alone has not reproduced/fixed the reported symptom.

Other Claude findings were triaged rather than blindly applied:

• DesktopDirectoryPickerProviderImpl and platform/DesktopFilePicker write the directory flag without finally restoration and need follow-up. These are pre-existing writers outside the changed picker; the new file picker correctly states its own mode even when the ambient flag is wrong. Their migration can be separate, but record the remaining writers explicitly.
• Raw suggested save names and string path joining are pre-existing behavior; investigate compatibility before expanding that contract here.
• The proposed JWindow owner-chain fix is based on a false premise: KeyboardFocusManager.getActiveWindow already returns only Frame/Dialog (or null), and resolves a focused child to its owning Frame/Dialog. Official contract: https://docs.oracle.com/en/java/javase/26/docs/api/java.desktop/java/awt/KeyboardFocusManager.html#getActiveWindow(). No speculative owner rewrite made.
• Package relocation, constant ordering and broad reflection/source-shape tests are not correctness blockers.

Claude review: https://github.com/risa-labs-inc/BossConsole/actions/runs/34736418629. No repeat review request. Marking this open PR draft under the review handoff policy until the two concrete callback/filter cases and required checks are resolved. #611 remains correctly closed as covered by this surviving implementation, with both contributors credited. No PR merged.

[arjun28115]

Pushed fa2b7d2, covering both substantive items. Neither is a consequence of the ownership change, and both are in Open and Save.

1. One result per pick. onResult was called inside the same try that catches picker failures, so a plugin whose callback threw got its path and then a null immediately after. null is indistinguishable from a cancel, so one pick produced two answers and the second was wrong.

Delivery now goes through deliverOnce, which sets its flag before invoking. That is the detail that makes it work: a throw from the plugin's callback cannot be retried by the catch, while a throw from the picker itself arrives before any delivery and so still reports the cancel. The two failures are told apart by when they happen rather than by inspecting the exception.

2. A dotted extension no longer empties the panel. The API takes List<String> and says nothing about spelling, so callers pass both csv and .csv, and every consumer appended its own dot: the macOS filter tested name.endsWith(".$ext") and Swing's FileNameExtensionFilter adds the dot itself. .csv was therefore matched as ..csv, which no file is named, so the filter hid every valid choice rather than narrowing to them.

I normalised rather than declaring a bare-extension contract, for the reason the bug is hard to notice: the contract is not checkable at the plugin boundary, and breaching it produces a panel that lists nothing, which reads as "there are no matching files here" rather than as a defect. Blank entries are dropped, and a blank-only list becomes empty, which every call site already treats as "no filter" rather than as a filter matching nothing.

On your last point about SAVE. I have not claimed the filter forces the output extension, and the Save path now carries a comment saying the opposite: a native SAVE panel narrows what is listed and does not constrain what the user types, so the returned path may still carry any extension or none.

Testability. The three helpers are internal and pure, so the rules are exercised without an AWT panel blocking the EDT. The provider calls exactly these, so reverting a call site is a compile error rather than a quietly unexercised test, which was the gap you named on the predicate tests earlier. Eleven tests: one delivery per pick, a throwing callback getting exactly one, a failure before delivery still reporting the cancel, only-the-first-survives, then csv / .csv / mixed case / whitespace / blank-only / empty / null filters, and that an empty list accepts everything rather than nothing.

Not taken here, matching your triage: the DesktopDirectoryPickerProviderImpl and platform/DesktopFilePicker writers of the directory flag without finally restoration. They are pre-existing writers outside the changed picker, and the new picker states its own mode regardless of the ambient flag. Recording them explicitly here so the remaining writers are not lost: those two are the ones left.

ktlint 1.8.0 is clean on both files and no line exceeds 120 columns. I run the pinned ktlint locally now rather than finding that out from code-quality. No local test run is claimed; the suite on this head is the real check.

[arjun28115]

Rebased onto current dev at 7fde917.

dev was force-pushed and its history rewritten, so the old tip is orphaned and every branch based on it went to dirty. Merging dev in does not work here: the branch still carries the old history, so the merge fights the rewrite across seventeen files this PR never touched. Replaying this PR's own commits onto the new base is the operation that fits, and it brings the diff back to what it should be.

Your commits are preserved in order with their authorship. The SHAs changed because a rebase rewrites them; nothing else did. I checked file by file that every file this PR touches is byte-identical to what the branch held before the rebase, so the only intended change is the base.

Flagging one thing rather than leaving you to find it: while rebasing #596 earlier I force-pushed over three of your commits on that branch before restoring them. I have since checked each branch's full history before touching it, which is what I should have done first. If you would rather I never rebase a branch you have commits on, say so and I will just tell you when one needs it.

[arjun28115]

The blocker you named is cleared. Current head e6cc0b0 has a full passing result on all ten checks: both database and code-quality, all three platform builds, compatibility, BOSS AI contracts, shell, version-check and build-summary. Nothing is pending and nothing is red.

The dev-integration recheck you listed as the other step is also done, and it needed doing for a different reason: dev was force-pushed and its history rewritten, so this branch was sitting at dirty against the new base. It is rebased onto current dev now, so the green result above is against the base it would merge into rather than an earlier one.

Marking ready is yours under the bounded-review policy, so I have not touched the draft flag. Flagging it because the condition you set has been met rather than leaving it to a poll.

[kshivang]

@claude Please review current head e6cc0b05e for merge into dev. Read your previous review and contributor follow-up first; focus on unresolved correctness/regressions and changed code. This is one current-head follow-up after contributor rebasing/repairs. For #548 verify storage identity routing and tests; for #552 verify callback once-only delivery, normalized filters, owner/mode/disposal and tests. Prior review triage remains in the thread; no native UI verification is claimed.

[claude]

Claude finished @kshivang's task in 5m 2s —— View job

---

Review: current head e6cc0b0 for merge into dev

• Re-read prior review + contributor follow-up
• Diff current head against the PR base (f91633d)
• fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: once-only delivery (deliverOnce)
• fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: filter normalisation
• fix(plugins): give a plugin's file panel an owner and its own directory mode (#551) #552: owner / directory mode / disposal
• fix(plugins): scope PluginStorageFactory.createStorage to the calling plugin's own id #548: provider routing + tests
• Test coverage assessment

Verdict: the two items you blocked on are genuinely fixed, and the fixture bug from my last pass is fixed and pinned. CI run 34759967202 is green on this exact head. I would merge this after the one cheap thing you already asked for and did not get (the in-tree record of the remaining writers, item 3). Item 1 is the only finding I would argue is worth doing in this PR rather than after it, and it is a judgement call.

---

Verified against the head

Once-only delivery - correct, and correct for the right reason. deliverOnce (FilePickerProviderFactory.kt:70-79) sets delivered before invoking, which is the whole trick: a throw out of the plugin's callback cannot be retried by the catch, while a throw from the picker itself arrives before any delivery so the catch's null is still the plugin's one answer. The two failures are separated by when they happen rather than by inspecting the exception, which is the only classification that actually works here. The no-synchronisation note is right too: both the delivery sites and both catch blocks are inside SwingUtilities.invokeLater, and invokeLater gives the happens-before for the flag written on the caller thread. Both pickFile and pickSaveFile route every one of their four exits through deliver.

Filters - the dot case is fixed. normalizedExtensions (:38-42) trims, strips one leading dot, trims again, drops blanks; matchesAnyExtension (:50-53) is case-insensitive on both sides. csv and .csv now select the same files on both the macOS and the JFileChooser branch, and a blank-only list collapses to empty, which both branches already read as "no filter". Gap in item 1 below.

Owner - fine, and your triage of my finding 5 was right. getActiveWindow() returns only a Frame, a Dialog, or null, so the else -> at OwnedFileDialog.kt:39 is the null branch and there was nothing to walk. No speculative rewrite was the correct call.

Directory mode - correct. showModal states the mode immediately before showing and withDirectoryMode unwinds in reverse, clearing an absent property rather than writing "false" back. The nesting case (OwnedFileDialogTest.kt:78-93) is the one that matters and it is pinned.

Disposal - correct. dispose() is in its own finally wrapping withDirectoryMode, so a throw from System.setProperty cannot skip it, which the pre-extraction version could. Reading dialog.directory / dialog.file after dispose() is safe (the peer writes those fields during the modal show and dispose does not clear them) and matches what NativeFileDialogs.showOpen already does, so the two files stay consistent.

The fixture bug is fixed and pinned. OwnedFileDialogTest.restore() (:34-42) no longer relies on setProperty's return, and fixture teardown preserves a property present before setup (:107-113) constructs a second instance and drives capture/restore through it, so the teardown is tested rather than assumed. That is the right shape for this.

Tests: 19, and they are the right 19. Eight on the property discipline, eleven on delivery and filters, all against pure internal helpers so nothing needs a display.

---

1. The filter normaliser handles one spelling out of three, and duplicates one that handles all three - FilePickerProviderFactory.kt:38-53

fileDialogSuffixes and matchesSuffix already exist, internal, in the same module (NativeFileDialogs.kt:376-386), for this exact job. The new pair differs in two ways and both are visible to a plugin author:

• *.csv and text/csv still empty the panel. fileDialogSuffixes drops the whole filter when any token contains * or /, because a filter it cannot express as suffixes must degrade to "no filter" rather than to "matches nothing". normalizedExtensions keeps *.csv as a literal token, so matchesAnyExtension tests endsWith(".*.csv") and the Swing branch hands FileNameExtensionFilter an extension no file carries - with isAcceptAllFileFilterUsed = false, that is the same empty panel the dotted case produced. *.csv is not an exotic guess: it is how Swing's own filter descriptions are written, and this file writes them that way itself two lines later ("*.$it").
• The two disagree about what an empty list means. matchesSuffix returns false, matchesAnyExtension returns true. Both are defensible with their call sites in front of you; neither is safe to read by name.

You framed the choice as "normalize consistently, or establish and enforce a bare-extension contract". The reasoning for normalising is right, and it applies with the same force to *.csv as to .csv: the plugin gets a panel that lists nothing, which reads as "no matching files here" rather than as a defect. Reusing the existing pair gets all three spellings and removes the third copy of suffix matching from a PR whose thesis is that these files must not drift. Fix this →

If you would rather not widen the contract in this PR, the smaller version is to keep the helpers and add the *// all-or-nothing rule plus two tests, and say in the KDoc why there are two copies.

2. The log still claims a cancel the plugin did not get - FilePickerProviderFactory.kt:147-157, 215-222

When the plugin's own callback throws, the exception lands in the catch and logs "File picker failed; the plugin will see this as a user cancel". The plugin got its path; it will see no cancel. deliver(null) correctly does nothing, so behaviour is right and only the diagnostics lie - but this is a message someone will read while debugging exactly this situation. deliverOnce already knows the answer; exposing it (return a small object, or a () -> Boolean) lets the catch say "the plugin's callback threw after delivery" instead. Small, and the only reason I rank it at all is that the whole point of the log line is to be the one place the difference exists.

3. The in-tree record you asked for is still missing - OwnedFileDialog.kt:27-29

You wrote "record the remaining writers explicitly". They are recorded in your comment thread and in Arjun's reply, and nowhere in the tree. The deleted showModal KDoc was the only in-tree list and it named the sites; the replacement says only that NativeFileDialogs "recorded that every other FileDialog in the tree should be routed through the same helper", which no longer points at anything. Confirmed still outstanding, four sites, two of them writers:

Site	Owner	States mode	Writes the flag	Disposes
providers/DesktopDirectoryPickerProviderImpl.kt:38,48,55	Frame only	no	yes, "false", no finally	no
platform/DesktopFilePicker.kt:43,45,51	no	no	yes, "false", no finally	no
platform/FilePicker.kt:41,99	no	no	no	no
settings/shared/SettingsComponents.kt:875	no	no	no	no

Two consequences worth having written down next to the helper rather than only in a PR thread:

• DesktopDirectoryPickerProviderImpl has no try/catch around isVisible = true (the only try in that function, :22-31, wraps the look-and-feel call). A throw escapes the invokeLater body, so the flag stays "true" for the process and onResult is never called, leaving the plugin waiting with no cancel. That is the sticky state the new picker is immune to and the other three sites are not.
• Both writers write "false" rather than restoring, so after one host directory pick the process-wide property is permanently set. withDirectoryMode then faithfully restores "false", which is functionally the same as absent for the peer, but the "absent stays absent" invariant OwnedFileDialogTest:55 pins is defeated process-wide by code outside this PR. Worth a sentence so the next reader does not conclude the test proves more than it does.

Fix this →

4. Two dead imports - NativeFileDialogs.kt:12,14

java.awt.Dialog and java.awt.Frame are now referenced only from a backticked KDoc phrase at :295; the owner when that used them moved to OwnedFileDialog.kt. ktlint's no-unused-imports did not flag it (CI is green, and the rule counts KDoc text), so nothing gates this - it is a one-line tidy while the file is open.

While you are at :290-296: that KDoc still says "Same fix as DirectoryPickerProviderImpl, except that one only handles a Frame owner." It now describes a helper it delegates to, and it is the last in-tree pointer at the unfixed file, so it is the natural place for item 3's list.

5. Carried, and deferred by your triage - not re-arguing, just noting they are unchanged

• pickSaveFile still passes suggestedFileName to dialog.file raw (:173-175), where NativeFileDialogs.showSave uses safePrefill. The suggestion comes from a plugin, and safePrefill is internal in the same module. Your "investigate compatibility first" is fair; the compatibility question is narrow, since safePrefill only takes the last path segment and drops control characters.
• "$dir$file" (:120, :186) still depends on getDirectory() carrying a trailing separator, which FileDialog does not document. File(dir, file).absolutePath is what the rest of the module uses.
• The SAVE-filter caveat is now written at :176-177 and matches what you asked for: it narrows what is listed, it does not constrain what is typed. No over-promise anywhere in the file.

6. Coverage, in descending value - unchanged from last pass

1. Nothing fails if someone writes FileDialog(null as Frame?, ...) again, which is the defect this PR exists to remove. A source-shape test scanning composeApp/src/desktopMain for FileDialog( outside OwnedFileDialog.kt against a shrinking allowlist of the four sites in item 3 would give the fix teeth and make the record in item 3 self-maintaining. The repo already pins this class of invariant against source (OsOpenArgumentsTest, FileTypeCategoriesTest).
2. The owner branches are untested. Deleting is Dialog -> from ownedFileDialog fails nothing. Extracting internal fun fileDialogOwner(active: Window?): Window? - pure, taking the window rather than reading the focus manager - makes the classification reachable from a headless test. AGENTS.md's mutation-verification standard for pluginSectionAbsence is the bar.
3. showModal's dispose-in-finally is untested and cannot be from a headless JVM. The KDoc at :68-76 correctly scopes its "each of which has a test" claim to withDirectoryMode, so this is fine as it stands.

Minor: OwnedFileDialogTest mutates a process-wide property, so it would need isolation if desktopTest ever turned on parallel execution within the JVM. Not a problem today.

---

#548

Wrapper routing is intact on this head, unchanged by the rebase:

Provider	DefaultPlugin	TrackingPluginContext	SandboxedPluginContext
filePickerProvider	:867	:406	:240
directoryPickerProvider	:892	:411	:247
pluginStorageFactory	forwards	:388	forwards

Still nothing pins it, and this exact regression has shipped: docs/release-notes/v9.2.35.md:22-23 records directoryPickerProvider and projectDataProvider falling through to the interface default null in both wrappers, so "Open Project" and Evolve's "Browse" silently did nothing. AGENTS.md states the three-wrapper rule as a rule with no test behind it. A ~15-line reflection test asserting every PluginContext provider val is declared override in TrackingPluginContext and SandboxedPluginContext is the highest-value missing test in this area, and it belongs to whichever PR the group consolidates into rather than to this one.

On storage identity specifically: pluginStorageFactory is forwarded by all three wrappers, but the identity a storage instance is created under is decided by the caller, not by the wrapper, and nothing in this head touches it - the diff is five files, all picker. So I can confirm the routing is not broken by this PR and cannot confirm anything about identity correctness from it. If #548 covers storage identity, it needs its own diff to review.

---

What I could not verify

./gradlew is not runnable here (fetch and build commands are not approved in this environment), so I did not execute OwnedFileDialogTest, FilePickerDeliveryTest, ktlintCheck or detekt myself - I am taking the green CI run on this head as the evidence for those. No native UI verification is claimed or attempted; the manual checks in the PR body (Frame and Dialog ownership, cancellation, a plugin pick nested inside the browser's folder panel, peer release over repeated picks) are still the only way to close items the source cannot answer. Findings 1 through 4 are static and need no display.
· branch fix/plugin-file-picker-owner

[kshivang]

@arjun28115 Current-head review is complete. Your callback delivery and dotted-extension repairs resolve both substantive handoff items. Downloaded current-head macOS test reports confirm 11 delivery/filter + 8 owned-dialog + 11 native-dialog tests, all passing; all ten hosted checks pass. @JaspreetSingh33’s #611 work and co-author credit remain preserved.

Latest Claude review: https://github.com/risa-labs-inc/BossConsole/actions/runs/34804614330. Final triage:

1. MIME/glob semantics are not a blocker for this extension API. boss-plugin-api/FilePickerProvider.kt:15 explicitly documents file extensions (json, txt), unlike browser HTML accept, whose MIME/glob semantics motivate fileDialogSuffixes. Workspace callers use bare extensions or no filter. Automatically dropping all filtering for text/csv or *.csv would widen accepted choices, not implement the extension contract. Dotted suffix compatibility is handled; broader syntax/shared helpers can be considered separately. Declining this requested expansion here with that evidence.
2. Callback-failure log wording is imprecise, not a remaining delivery defect. Once-only delivery is correct on every Open/Save exit; callback exceptions cannot cause a second cancel. The error message can still describe a cancel that was suppressed. Treat this as a nonblocking diagnostic follow-up, not grounds to replace the already-validated delivery design.
3. Remaining native-dialog sites are recorded explicitly here and in the surviving PR description: components/plugin/providers/DesktopDirectoryPickerProviderImpl.kt and platform/DesktopFilePicker.kt write the directory flag without finally restoration, resetting to false rather than preserving absence; platform/FilePicker.kt and components/settings/shared/SettingsComponents.kt still contain separate dialogs. Their pre-existing behavior and moving this list back into KDoc are follow-up scope; this helper correctly restores its own entry state. The earlier request said to record them explicitly, not that source relocation was a correctness gate.
4. Import/KDoc tidying and broader owner/wrapper source tests are nonblocking. The claim that reverting provider call sites necessarily fails compilation is overstated: helper tests validate helpers, and I reviewed provider wiring directly. No native owner/disposal coverage is claimed.
5. Suggested-name sanitization, string path joining and other picker migrations remain pre-existing compatibility follow-ups. Native Fluck Attach reproduction, Frame/Dialog Open/Save, cancellation, nested folder/file mode and repeated disposal checks remain unperformed. This addresses source-established defects; it does not claim The plugin file picker opens an ownerless AWT FileDialog, so a plugin's file-pick can go nowhere #551’s symptom is reproduced or fully closed.

No unresolved substantive correctness/security/regression issue remains in this change. Proceeding with a locked exact-head squash merge into dev after refreshing dev/state/mergeability/checks. No production-code changes by this sweep; the new delivery/filter code and tests are your contributor work, separate from prior agent integration/fixture repairs.