[max-sixty]

wt config plugins claude uninstall cannot finish a half-done uninstall. It returns early on !is_plugin_installed(), so once the plugin is gone the command stops there — and the state where the plugin is gone but the marketplace is not is exactly what a first run leaves behind when the plugin uninstall succeeds and the marketplace removal then fails. Re-running prints Plugin not installed and exits 0 with the marketplace still configured, and nothing in wt will remove it.

The early return now requires both halves to be gone, and takes only a confident Some(false) for the marketplace, matching what run_plugin_removal is willing to trust. The plugin step becomes conditional, and the ? preview lists it only when it will run, so the preview stays equal to the set of commands the uninstall spawns — the property test_plugins_claude_prompt_previews_commands pins.

The marketplace removal still runs unconditionally. Gating it on the config reading Some(false) was the first thing I tried, and it is wrong: it makes run_plugin_removal's tolerance unreachable in the cases that exercise it, so test_plugins_claude_uninstall_tolerates_absent_marketplace and its siblings would pass while never attempting the removal they exist to tolerate. Leaving the removal unconditional keeps that tolerance the thing that decides whether an absent marketplace is a failure.

test_plugins_claude_uninstall_removes_marketplace_left_without_plugin covers the recovered state: no installed_plugins.json, a known_marketplaces.json holding worktrunk, and a run that skips the plugin step and removes the marketplace. Every other uninstall snapshot is unchanged, which is what confirms this reaches only the state that was previously unreachable.

wt config plugins claude uninstall --help promised the opposite of the new behavior — "Skips gracefully if the plugin is not installed, leaving the marketplace in place" is precisely the state the command no longer skips — so it now states the real condition. Nothing caught that: the string is in no generated mirror and no snapshot, so test_docs_are_in_sync and the help snapshots both stayed green while the sentence described behavior that was gone. Both uninstall pages are test_help cases now, since what each says about skipping depends on what the harness's config still holds.

The Codex uninstall has no equivalent stranded state, which is measurable rather than a judgment call: codex plugin remove exits 0 on an absent plugin, so its first step never blocks the re-run from reaching the marketplace step. claude plugin uninstall exits 1 there, which is what made the is_plugin_installed guard necessary on that side and gave it a state to strand.

Raised as a non-blocking observation on #4033. It is pre-existing rather than introduced there, but it is in the function that PR was editing.

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

[worktrunk-bot]

The fix and its test read right, and the reasoning in the body for keeping the marketplace removal unconditional is convincing — gating it would make run_plugin_removal's tolerance unreachable in exactly the tests that exist to exercise it. One doc gap, and one question about the sibling harness.

wt config plugins claude uninstall --help now contradicts the code. src/cli/config.rs:445 promises the opposite of the new behavior:

Skips gracefully if the plugin is not installed, leaving the marketplace in place.

After this PR, plugin-gone-but-marketplace-present is precisely the state the command no longer skips — it removes the marketplace, which is the whole point. Nothing catches this: the string appears in no snapshot and no generated mirror, so test_docs_are_in_sync and the --help snapshots stay green while the sentence describes behavior that's gone. Per CLAUDE.md → Documentation, "does --help still describe what the code does?"

It's outside the diff, so no inline suggestion — the line, with a proposed replacement:

        after_long_help = r#"Uninstalls the Worktrunk plugin from Claude Code and removes its marketplace. Skips gracefully only when both are already gone; when one half is left — what a partly-failed uninstall leaves behind — it removes that half. Equivalent to:

Happy to push that as a commit if you'd like it.

Does the Codex uninstall have the same stranded state? handle_codex_uninstall in src/commands/config/codex.rs runs codex plugin remove worktrunk@worktrunk through plain run_plugin_cli — unconditionally, with no tolerance wrapper and no Codex counterpart to is_plugin_installed. So if codex plugin remove exits non-zero on an absent plugin the way both harnesses' marketplace remove does (per run_plugin_removal's docstring), a Codex uninstall whose second step failed can't be finished either: the re-run dies at the first step and the marketplace stays. Same shape as the bug here, reached from the other end. I can't determine Codex's exit behavior from CI, so this is a question rather than a claim — if it does exit non-zero, it'd want its own fix rather than being folded in here.

[max-sixty]

Both taken, in 89df894.

The help string. You're right that it promised the opposite, and right that nothing caught it. I wrote my own phrasing rather than the suggestion, keeping the Equivalent to: block where it was and putting the skip condition after it:

Skips gracefully only when both are already gone. An uninstall that removed the plugin and then failed leaves the marketplace behind; running it again removes that half.

The "nothing catches this" half seemed worth closing too, so both uninstall pages are now test_help cases. What each says about skipping depends on what the harness's config still holds, which is the part most likely to drift again.

The Codex question — no, it doesn't have the same stranded state, and it's measurable rather than a judgment call. I probed the real CLI earlier in a throwaway CODEX_HOME, and codex plugin remove is the one removal of the four that tolerates an absent target:

command	target absent	exit
claude plugin marketplace remove worktrunk	Marketplace 'worktrunk' not found	1
claude plugin uninstall worktrunk@worktrunk	not found in installed plugins	1
codex plugin marketplace remove worktrunk	is not configured or installed	1
codex plugin remove worktrunk@worktrunk	reports Removed plugin	0

So handle_codex_uninstall's first step exits 0 whether or not the plugin is there, and the re-run always reaches the marketplace step. That is also why the guard this PR fixes is Claude-only: claude plugin uninstall exits 1 on an absent plugin, which is what made is_plugin_installed necessary there and gave it a state to strand.

Same measurement is what established that run_plugin_removal was needed at all, on the marketplace remove rows.

[worktrunk-bot]

Confirmed against 89df894 — both resolved, and the new help wording matches the handler: the early return needs !plugin_installed && is_marketplace_configured() == Some(false), so plugin-gone-marketplace-present is exactly the case that now proceeds.

Thanks for the exit-code table — that closes the Codex question in the direction I couldn't measure from CI. One thing that follows from it and holds up on the code: the Codex uninstall page makes no skip claim at all, which is the right page for a command whose both steps tolerate an absent target, so the new snapshot has nothing to drift away from there.

[worktrunk-bot]

The help string now matches the guard, and the Codex measurement settles the sibling question cleanly — codex plugin remove exiting 0 on an absent plugin is exactly why that handler has no stranded state to fix, which is a better answer than the symmetry I was guessing at. Snapshotting both uninstall pages closes the "nothing catches this" half.

One optional suggestion inline, on the line this PR rewrites.