Add read-only structured project-command approval status #3698

Activity

1. worktrunk-bot commented on Aug 1, 2026

   

   worktrunk-bot

   on Aug 1, 2026

   Collaborator

   More actions

   Thanks for the suggestion — this is a reasonable gap to close, and the read-only three-state distinction you want is already computed internally; it just isn't emitted in a machine-readable form yet.

   wt config approvals list is the closest existing surface. It's read-only, never prompts, and never mutates state, and it already partitions into exactly the states you describe: it reports "No commands configured in project" when there are none, and otherwise splits the project's commands into APPROVED / UNAPPROVED sections (plus a separate list of stale approvals — commands approved earlier but since edited or removed from the config). The one thing missing is a structured format: today it only renders paged human text with no --format flag.

   So the smallest change that satisfies the request is to add --format=json to the existing list subcommand rather than introduce a new status subcommand. That matches how worktrunk exposes structured output elsewhere — wt config show --format=json, wt config state get --format=json, wt config state logs --format=json, wt list --format=json — all add a format flag to a read command instead of forking a parallel machine-readable command. Reusing list also means the JSON automatically carries the stale-approvals dimension, which an orchestrator scheduling non-interactive runs will care about (a stale approval means the saved approval no longer covers the current command template, so --yes would re-approve a changed command).

   A couple of design points a maintainer would want to settle before implementation:

   • New subcommand vs. flag. wt config approvals list --format=json fits the established pattern; a dedicated status verb would be a second way to read the same state. The --format flag on list seems preferable, but that's a call for a maintainer.
   • The four states, not three. The JSON should distinguish approved, unapproved (approval-required), stale, and no-commands — collapsing stale into either bucket would lose the signal above.

   This also reads as one of a cluster of requests aimed at making Worktrunk drivable by external orchestrators (#3696, #3697, #3699, #3700); worth a maintainer looking at them together, since a shared JSON convention across them would matter more than any one command's shape.

   I'll leave it for a maintainer to evaluate and prioritize. If they're happy with wt config approvals list --format=json as the shape, this is a localized change I'm glad to implement.

   Sources

   • Approvals CLI surface (no --format today): src/cli/config.rs lines 234-278
   • The three/four states are already computed in list_approvals: src/commands/config/approvals.rs lines 53-130 — the commands.is_empty() && stale.is_empty() no-commands branch, the approved/unapproved partition, and the separate stale section.
   • Structured-output precedent on read commands: SwitchFormat { Text, Json } in src/cli/mod.rs lines 209-212, used by wt config show, wt config state, and wt list.
   • Docs: wt config approvals
2. max-sixty

   closed this as completedin #3710on Aug 2, 2026
3. pull

   added a commit that references this issue on Aug 2, 2026

   feat: machine-readable approval state and branch-removal outcomes (ma…

   ...

   5c42c5b