Agent Mode: remove projects without deleting tasks

[AnthonyRonning]

Summary

• adds an accessible project actions menu and non-destructive Remove Project confirmation
• keeps removed projects hidden across relaunches and mode switches while preserving tasks, history, MCP state, and skills trust
• restores the same canonical folder at the top; supports offline removal and blocks removal while a task is running
• stores removed-root metadata per account and device, including Windows roaming-profile isolation

Closes #682.

Validation

• repository pre-commit: Prettier, production frontend build, and 220 frontend tests
• Rust all-target tests: 165 passed; 2 model-backed OCR/TTS tests skipped
• targeted persistence coverage for device-local state, roaming-config scrubbing, cross-device isolation, and failed local serialization

Review notes

• no Windows roaming-profile runtime or interactive desktop smoke test was run
• native stale start/send calls against already-hidden roots remain defense-in-depth follow-up work; normal UI flows and new-task creation are guarded

[cloudflare-workers-and-pages]

Deploying maple with    Cloudflare Pages

Latest commit:	16f2ecd
Status:	✅  Deploy successful!
Preview URL:	https://71804d02.maple-ca8.pages.dev
Branch Preview URL:	https://codex-maple-agent-remove-pro.maple-ca8.pages.dev

View logs

[marksftw]

testing the UX

[marksftw]

ran trough the acceptance criteria tests. works great.

I didn't have any MCP connections or skills in the environment. that's a gap I'll fill in future testing.

[marksftw]

automated review:

I reviewed PR #689 against the feature spec from a product UX perspective, focusing only on major requirement gaps.

The review was performed on commit 792357a. The PR branch has since been force-updated to 162e4c0, which I built but have not fully re-reviewed.

Overall result

The implementation substantially met the specification. I found one major UX gap:

• If removing a project fails to persist, the confirmation dialog remains open while the error appears behind the modal. The user effectively sees no feedback and may think the Remove button is broken. The error should be displayed directly inside the dialog with retry and cancel options.

Successfully validated

• Every project has an accessible ellipsis menu and Remove Project action.
• Confirmation clearly names the project, shows its path, and explains that files and tasks are preserved.
• Removed projects and their tasks disappear from the sidebar and project selector.
• Project removal persists across mode switches and app relaunches.
• Selection falls back to the next project, or the previous one when necessary.
• Remaining projects retain their relative order.
• Re-adding the same canonical folder restores its task and trust choice at the top.
• A renamed folder is treated as a distinct project.
• Missing/offline folders can still be removed.
• Removing the final project produces a stable empty state without projects reappearing.
• Removal did not alter the actual folders on disk.

Testing limitations

The disposable dev account returned 403 Usage limit reached, so I could not keep an Agent task running long enough to test the running-task removal guard live. Static review showed the intended disabled action and “Stop Agent Before Removing Project” explanation.

Account/device isolation and persistence-failure behavior were also reviewed through the code rather than destructive live testing.

[AnthonyRonning]

Thanks for testing this, Mark, and for catching the persistence-failure UX gap. We’ve updated the removal dialog so persistence errors now appear in place with Retry and Cancel, and the focused frontend/native validation plus the completed CI checks are green. We’re going ahead with the merge now.