Scheduling selected folder can show Access is denied, then closing app shows Window.Dispose error

[SevWren]

This was generated by AI during triage.

Bug Report

Summary

In DailyMotivation.exe main mode, after the user selects a folder and clicks Schedule Reminder, the App can show an Invalid Folder dialog containing Access is denied.. After that dialog is dismissed, closing the App can show a second error dialog:

Daily Motivation Brain Helper
Method invocation failed because [System.Windows.Window] does not contain a method named 'Dispose'.

Reporter Evidence

The annotated screenshot supplied during triage shows this sequence:

1. User runs DailyMotivation.exe from the repo/build folder.
2. In the Folder Scheduler main window, the selected folder is displayed as:
   C:\Users\mmuel\Desktop\acl_backups
3. User clicks Schedule Reminder.
4. A native Windows dialog titled Invalid Folder appears with the message:
   Access is denied.

The reporter also observed that, after dismissing the Access is denied popup, closing the App produces the System.Windows.Window / Dispose method error shown above.

Triage Classification

Category: bug
State: ready-for-agent

Triage Notes

This was not reproduced in an automated Windows run during triage. The report is still actionable because the screenshot and follow-up error provide exact user-visible symptoms and the source has obvious related seams:

• Main mode schedules through a selected folder path and shows validation failures with the Invalid Folder title.
• The scheduling path validates folders with Test-Path ... -PathType Container; access/ACL failures can surface as user-facing permission errors rather than a clear, recoverable validation state.
• Main-window cleanup calls Dispose() on a WPF System.Windows.Window, but that type does not expose a Dispose() method. This matches the close-time popup reported by the user.
• Popup-window cleanup has a similar guarded Dispose() call; check both main and popup modes so the fix does not leave a parallel latent issue.

Agent Brief

Category: bug

Summary: Scheduling a Selected Folder with restricted access should fail gracefully, and closing the App must not show a System.Windows.Window.Dispose error.

Current behavior:

When a user selects a folder and clicks Schedule Reminder, the App may show an Invalid Folder dialog containing the raw permission error Access is denied.. The selected folder from the report is C:\Users\mmuel\Desktop\acl_backups.

After dismissing that dialog, closing the main window can show another error dialog stating that [System.Windows.Window] does not contain a method named Dispose.

Desired behavior:

If the Selected Folder exists but cannot be accessed due to permissions, the App should show a clear, non-crashing validation message that explains the folder cannot be scheduled because access is denied. The App should recover cleanly: the Schedule button state should remain coherent, no MotivationTask or OS Task should be created, no PopupConfig should be written for the failed Schedule, and the user should be able to choose a different folder or close the App.

Closing the App after any failed Schedule attempt must not show an additional error dialog. WPF windows should be closed and cleaned up using APIs actually available on System.Windows.Window; disposable resources owned by the window should still be stopped/released where appropriate.

Key interfaces:

• Main mode folder validation for a Selected Folder before Schedule creates a MotivationTask.
• The scheduling function that returns Success, IsDuplicate, IsNetworkPath, and Error should distinguish inaccessible folders from missing folders where practical.
• Main-window cleanup after ShowDialog() must not call a nonexistent Dispose() method on System.Windows.Window.
• Popup-window cleanup should be checked for the same invalid WPF window disposal pattern.
• Tests should respect this repo's Windows 10 PowerShell 7 validation rules from CLAUDE.md: regular Windows UI/Task Scheduler behavior must be validated on Windows, while platform abstraction tests alone are not sufficient.

Acceptance criteria:

• Selecting a folder that exists but is not accessible to the current user and clicking Schedule Reminder does not create a MotivationTask, OS Task, or PopupConfig handoff for that failed Schedule.
• The user-facing error for an inaccessible Selected Folder is clear and intentional, e.g. it communicates that access is denied or the folder cannot be accessed, without exposing a raw exception dump.
• After dismissing the access-denied validation dialog, closing the main window produces no additional error dialog.
• No code path calls Dispose() directly on a System.Windows.Window instance unless guarded by a real IDisposable check.
• Any timers, XML readers, mutexes, dialogs, and other disposable resources still get cleaned up correctly.
• Add or update Pester v5 tests for the folder scheduling validation behavior and for the WPF window cleanup regression where practical.
• Validate the fix on Windows 10 PowerShell 7, not only in Linux/Unix platform abstraction tests.

Out of scope:

• Changing the overall scheduling UX or adding a new folder picker flow.
• Changing Task Scheduler registration semantics for valid, accessible folders.
• Reworking the compiled ps2exe build pipeline.
• Treating this as a request to support scheduling folders the current user cannot access.

[SevWren]

This was generated by AI during triage.

Additional Triage Evidence

The reporter provided a second screenshot and clarification that the first issue body was too narrow.

Important correction

This is not limited to folders the user cannot access. The reporter states the selected folder is 100% verified accessible to their Windows user.

Additional reproduction surface

The bug also appears through the Context Menu Verb / setfolder flow:

1. In Windows Explorer, navigate to C:\tmp.
2. Right-click an accessible folder, shown in the screenshot as mattpocock-skills.
3. Use the App's folder scheduling context-menu action.
4. The App shows a custom dark dialog titled Schedule Failed.
5. The dialog body says:

Could not schedule '[PATH]'

Access is denied.

Updated understanding

The issue should be investigated across both scheduling entry points:

• main mode: selecting a folder in the Folder Scheduler window and clicking Schedule Reminder.
• setfolder mode: scheduling from Explorer via the Context Menu Verb.

Because the failing folder is user-accessible, the likely failure may be OS Task registration / Task Scheduler principal / run level / executable path / context-menu invocation behavior, not just filesystem ACL validation. The Access is denied message may be coming from Register-ScheduledTask, context-menu registration/invocation, or another Windows integration seam after folder validation has already passed.

The issue title and acceptance criteria remain broadly valid, but implementers should not solve it by treating all Access is denied cases as inaccessible Selected Folders. A valid fix must preserve scheduling for normal accessible folders and identify which Windows integration call is actually returning access denied.

Additional acceptance criteria

• Scheduling an accessible local folder via the Explorer Context Menu Verb succeeds or reports a precise failure cause that identifies the failing Windows integration step.
• The App does not mask an accessible FolderPath failure as a folder-access problem when the real failure is OS Task registration, principal configuration, executable invocation, or another integration step.
• The failure dialog should include enough non-sensitive context for support/debugging; if the path is sanitized to [PATH], the error should still name the operation that failed.
• Tests or manual Windows validation cover both main mode scheduling and setfolder mode scheduling for an accessible local folder.

[SevWren]

This was generated by AI during triage.

Corrected Agent Brief

Category: bug

State: ready-for-agent

Summary: Scheduling an accessible local folder can fail with Access is denied in both main mode and setfolder mode, then closing the App can surface an invalid WPF Window.Dispose() error.

Current behavior:

Two user-visible scheduling failures have been reported:

1. In main mode, the user selects a folder, clicks Schedule Reminder, and gets an Invalid Folder dialog containing Access is denied.. Closing the App afterward can show:

Method invocation failed because [System.Windows.Window] does not contain a method named 'Dispose'.

2. In setfolder mode, the user right-clicks a normal accessible local folder in Explorer and invokes the App's Context Menu Verb. The App shows a custom dark dialog titled Schedule Failed:

Could not schedule '[PATH]'

Access is denied.

The second report is important: the folder is confirmed accessible to the current Windows user. Do not treat this issue as only a restricted-folder validation bug.

Triage evidence from codebase inspection:

• The Context Menu Verb invokes the compiled Exe as /setfolder "%1".
• setfolder mode checks Test-Path $FolderPath -PathType Container, then calls New-MotivationTask.
• New-MotivationTask creates an OS Task using New-ScheduledTaskPrincipal with UserId = $env:USERNAME, LogonType = 'S4U', and RunLevel = 'Limited'.
• Register-ScheduledTask is the most likely seam for the observed Access is denied after folder validation succeeds. Existing tests already mock Register-ScheduledTask { throw 'Access Denied' }, but they only assert generic failure/no persistence; they do not verify the user-facing diagnosis or the setfolder flow.
• Show-MainWindow calls $window.Dispose() after ShowDialog(). WPF System.Windows.Window does not provide Dispose(), matching the reported close-time popup.
• Show-PopupWindow contains a guarded $window.Dispose() call too; review it so the same bad assumption does not survive elsewhere.
• Existing UIDisposal.Tests.ps1 currently asserts the opposite of reality with the message "WPF Window implements IDisposable and must be disposed". That test should be corrected, not preserved.

Desired behavior:

Scheduling an accessible local folder should work from both entry points:

• main mode: selected folder + Schedule Reminder
• setfolder mode: Explorer right-click Context Menu Verb

If scheduling fails, the App should report the failing operation precisely enough to distinguish folder validation from OS Task registration/principal failures. It should not imply the selected folder is invalid or inaccessible when the folder itself is accessible and the failure occurred while registering the OS Task.

After any failed scheduling attempt, closing the App must not produce a secondary Window.Dispose() error. WPF window cleanup should stop timers and release genuinely disposable resources, but should not call nonexistent methods on System.Windows.Window.

Key interfaces:

• New-MotivationTask result contract: should preserve enough failure information for callers to distinguish validation, action creation, principal creation, OS Task registration, JSON persistence, and duplicate detection failures.
• setfolder mode error handling: should show a useful Schedule Failed message without misleading the user or over-sanitizing the operation context.
• main mode error handling: should avoid presenting OS Task registration failures as Invalid Folder failures.
• Context Menu Verb registration/invocation: should pass the selected folder path correctly and use the compiled Exe path.
• Task Scheduler principal/registration configuration: investigate whether S4U + $env:USERNAME is valid for this App's intended no-admin per-user scheduling model on Windows 10.
• WPF window lifecycle cleanup in main mode and popup mode.

Acceptance criteria:

• Scheduling an accessible local folder from main mode succeeds on Windows 10 PowerShell 7, or fails with a precise diagnostic naming the actual failing operation.
• Scheduling an accessible local folder from the Explorer Context Menu Verb succeeds on Windows 10, or fails with a precise diagnostic naming the actual failing operation.
• OS Task registration failures are not shown as Invalid Folder unless folder validation truly failed.
• A Register-ScheduledTask access-denied failure returns a structured/recognizable scheduling failure that callers can display accurately.
• Failed scheduling does not write a MotivationTask, OS Task, or PopupConfig handoff.
• Closing the main window after a failed schedule attempt never shows System.Windows.Window / Dispose errors.
• No production code directly calls Dispose() on System.Windows.Window unless the object is first proven to implement System.IDisposable.
• Tests are updated so they no longer assert that WPF Window must be disposed directly.
• Add or update Pester v5 coverage for Register-ScheduledTask access-denied behavior, setfolder-mode failure messaging where practical, and the WPF window cleanup regression.
• Final validation includes Windows 10 PowerShell 7 behavior. Linux/platform abstraction tests alone are not sufficient for this bug.

Out of scope:

• Changing the App's overall scheduling UX.
• Adding admin-required scheduling.
• Supporting folders the current user truly cannot access.
• Reworking the ps2exe build pipeline.
• Removing path sanitization wholesale; improve diagnostics without leaking unnecessary sensitive paths.

Triage recommendation:

Keep issue #10 labeled bug and ready-for-agent. The issue is sufficiently specified for an implementation agent, but the corrected brief above should supersede the original body where they conflict.