Two operations report success or appear available but do nothing: `workflows delete` is a no-op, and a community's Repos Directory cannot be cleared

Two separate defects, filed together because they share a shape: an operation presents as available and returns success, while nothing changes. Both cost real debugging time before the cause was found in the source.

Versions: Buzz Desktop and `buzz` CLI as of 2026-08-23, macOS 15 (arm64). Happy to split this into two issues if you'd prefer.

---

## 1. `buzz workflows delete` returns `accepted: true` and does not delete

```
$ buzz --relay workflows delete --workflow
{"accepted":true,"event_id":"","message":""}

$ buzz --relay workflows list --channel
[... still present ...]
```

Repeated 30+ seconds later with the same result: still listed, and `workflows get --workflow ` still returns the full definition.

**Not an authorization failure.** The event is signed with the workflow owner's key — the same key that successfully performs `workflows update` against that exact workflow moments earlier. An auth failure also surfaces differently: exit 3 with `{"error":"auth_error"}`, not `accepted: true`.

**Why it matters:** there is no way to remove a workflow from a relay. A workflow deleted from a repo's manifest keeps its schedule and keeps firing, with nothing on the client able to remove it. The only mitigation we found is setting `enabled: false`, which the relay does honour — but that leaves an undeclared workflow on the relay permanently.

**What would help:** whether the CLI publishes a deletion event the kind:30620 handler ignores, or the relay accepts and does not act. `accepted` reading as a post-condition when it is only an event-acceptance receipt is the part that made this expensive to spot.

---

## 2. A community's "Repos Directory" cannot be cleared once set

**Repro:** set a Repos Directory on a community, save. Reopen **Edit Community**, clear the field, save. An error appears under the field and the value is not cleared. There is no Clear/Reset control.

**Cause**, `desktop/src/features/communities/ui/EditCommunityDialog.tsx`:

```js
const expandedReposDir = await expandTilde(reposDir); // "" stays ""
if (expandedReposDir !== community.reposDir) {
try { await validateReposDir(expandedReposDir ?? ""); }
catch (error) { setReposDirError(String(error)); return; } // <- always taken
updates.reposDir = expandedReposDir;
}
```

`validate_repos_dir` (`desktop/src-tauri/src/managed_agents/repos.rs`) trims the input and rejects a non-absolute path. `Path::new("").is_absolute()` is `false`, so the empty string returns `Err("repos dir must be an absolute path (got ``)")`, the handler returns before `onSave`, and nothing persists.

The comment immediately above that block states the intended behaviour:

> `// An empty field clears the override (REPOS reverts to a real dir).`

So the intent is explicit and the implementation does the opposite.

**Suggested fix:** short-circuit before validation when the trimmed value is empty, and pass the cleared value through — or accept `""` in `validate_repos_dir` as an explicit "no override".

**Workaround, for anyone who lands here:** quit the app, remove `reposDir` from the `buzz-communities` key in the WebKit localStorage store, relaunch. Editing it while the app runs does not stick — the community array is re-saved on any update.

---

### Related, possibly worth its own look

`ensure_repos_symlink` refuses when `~/.buzz/REPOS` is a non-empty real directory, which is correct — it would have to delete real checkouts. But the resulting toast names `~/.buzz/REPOS` while the user is looking at the path they just typed, so it reads as "the directory I entered is invalid". Naming the required action ("~/.buzz/REPOS must be empty or a symlink before a repos dir can be applied") would save the reader a source dive.

Start with desktop/src/features/communities/ui/EditCommunityDialog.tsx and desktop/src-tauri/src/managed_agents/repos.rs, then reproduce clearing a saved Repos Directory and verify the value persists as cleared. For the workflow defect, trace the CLI deletion event through the kind:30620 handler and confirm whether deletion is acted on; done means both operations produce the intended state changes and have regression coverage.

Written by the indexing model from the issue text.