feature request: option to approve user hooks

[endigma]

I wanted something like:

[[pre-start]]
trust = "gum confirm 'trust this worktree?' && mise trust || echo 'worktree not trusted'"

(which doesn't work, because hooks don't run interactively)

But as:

[[pre-start]]
trust = "mise trust"
confirm = "trust this worktree?"
# or?
confirm = { default = true , prompt = "trust this worktree?" }

going through worktrunk to give me a Y/n ( or y/N? see default ) I think that would be very useful for basic hooks like this. I want to mise trust 99.9% of worktrees I create as they are just variants of my own projects, but not necessarily every worktree.

---

Alternatives considered:

• I could add this to every project config I work on
• I could build some kind of shell script that arbitrates trustable directories by policy
• I could just type mise trust all the time
• I could put this in [projects."github.com/user/repo"] in user settings

However, I think of the above, none is as elegant as simply offering some basic control flow to global user hooks.

[worktrunk-bot]

Thanks for the suggestion. I searched the codebase and didn't find a per-execution confirm/prompt on hooks — Command in src/config/commands.rs carries only name and template, and the foreground hook executor pipes the JSON context to the child's stdin (see pipe_stdin in src/commands/command_executor.rs), which is why an inline gum confirm reading from stdin won't see a TTY.

The closest existing primitive is the approval system, but that's a one-time "allow and remember" gate for project commands, persisted in ~/.config/worktrunk/approvals.toml — it doesn't fire each time the hook runs and doesn't carry a custom prompt.

I'll leave it for a maintainer to evaluate and prioritize.

[max-sixty]

I could imagine two ways of doing this:

• Our existing approval system applied to user-hooks
• Allow foreground hooks to interact with stdin / TTY

@worktrunk-bot how feasible would the latter be? my guess is that it's possible for serial hooks but not for the concurrent hooks. and maybe that distinguishing those is hard. If it were possible, it would be nice & general

My initial reaction re the approval system for user hooks is that it's not really a security approval, which is what the existing approval system is for (and saves the approval, which seems like isn't what this case wants)

I'll leave this open to solicit views from others... thanks as ever @endigma

[worktrunk-bot]

Your intuition matches what I see in the executor.

Serial steps (HookStep::Single) — small lift. The foreground executor already supports inheriting the parent's TTY; it's just gated on pipe_stdin = false, which today only the alias path flips (command_executor.rs:572-584, then handlers.rs:1760-1769). Cmd::inherit_stdin() already keeps the child in the parent's pgroup so tcsetattr on /dev/tty doesn't trip SIGTTOU (shell_exec.rs:1024-1044).

Concurrent steps (HookStep::Concurrent) — not feasible, as you guessed. The prefixed-line executor unconditionally pipes each child's stdin to deliver the JSON context per-child (output/concurrent.rs:280-285), and even if we didn't, several children racing on one TTY isn't a usable shape.

Distinguishing them isn't hard — the config already splits serial from concurrent at parse time (HookStep::Single vs HookStep::Concurrent in config/commands.rs), so a per-step opt-in field (e.g. interactive = true on a Command) can be rejected at config-load when it appears inside a concurrent group. No runtime ambiguity to detect.

Caveats worth thinking through

• Documented JSON-on-stdin contract. Today every hook child gets template variables as JSON on stdin (docs/content/hook.md § JSON context). Flipping the default would break that for any hook reading sys.stdin; an opt-in flag (interactive = true ⇒ pipe_stdin = false) keeps it intact. An interactive hook that also wants the context has to use template vars ({{ branch }} etc.) — fine for the mise trust case, lossy for hooks that consume the full JSON.
• --yes. CommandContext::yes is already plumbed in; an interactive hook needs to either no-op the prompt or fail under --yes so CI / wt merge --yes doesn't deadlock.
• Scope. This only opens the door for the generic "let the child talk to the user" path. The specific ergonomics in the issue (a confirm = "trust this?" field that wraps the prompt, with default) would sit a layer above — a built-in shorthand for gum confirm / read -p so users don't need a TTY helper installed.

[max-sixty]

can we use the same approach we use for aliases?

[worktrunk-bot]

Yes — the alias path already pulls exactly the lever you want, and the dispatch is centralized so a hook variant is a small change.

Today both pipelines flow through the same sourced_steps_to_foreground conversion (hooks.rs:591-596), which hard-codes pipe_stdin = true for PipelineKind::Hook and false for PipelineKind::Alias. Downstream that bit is the only difference at the stdin layer — run_one_command reads fg_step.pipe_stdin and either sends context_json or calls inherit_stdin() (command_executor.rs:572-584, then handlers.rs:1760-1769).

So "same as aliases" reduces to: when a hook step opts in (e.g. interactive = true on a Command), set pipe_stdin = false for that step in the converter, and otherwise leave the JSON-on-stdin contract alone. The TTY plumbing (inherit_stdin() keeping the child in the parent pgroup so tcsetattr on /dev/tty succeeds — shell_exec.rs:1024-1044) is already proven by aliases; we'd be reusing it byte-for-byte.

What that touches

• ForegroundStep::pipe_stdin is already per-step, so the converter can branch per Command without restructuring.
• The concurrent guard goes at config-load: reject interactive = true inside a [[pre-merge.<group>]] table that parses to HookStep::Concurrent. Serial-only is enforced before any executor runs, matching what you noted about concurrent not being feasible.
• One adjacent difference from aliases stays opinionated for hooks: redirect_stdout_to_stderr = true (hooks.rs:592-594). For a gum confirm that writes its UI to stderr that's fine; for a read -p to stdout it would land on stderr instead. Probably acceptable (the prompt still renders) but worth flagging — could be coupled to the same opt-in if it bites.
• --yes semantics aren't decided by this lever; an interactive step needs to either no-op the prompt or fail under CommandContext::yes so wt merge --yes / CI doesn't deadlock. Same question whether we go alias-shaped or build a dedicated confirm = "…" shorthand on top.

[endigma]

I'd be happy if all hooks could be explicitly serialised and made interactive, as in the cmux issue sometimes post-x hooks being separate processes is also a footgun

Would make that hook more intuitive and also the confirmations work if we could add interactive = true to force it to foreground

[max-sixty]

Would make that hook more intuitive and also the confirmations work if we could add interactive = true to force it to foreground

but with concurrent ones I'm not sure this is possible...

[endigma]

Is there some constraint forcing some hooks to be concurrent or is that just an optimisation?

[worktrunk-bot]

No constraint — concurrency is purely a user-chosen TOML shape. The deserializer only emits HookStep::Concurrent when the user wrote a multi-key dict; every other shape becomes serial (config/commands.rs:14-18):

Shape	Result
hook = "cmd"	one serial step
hook = ["a", "b"]	one serial step per item
[hook] with 1 key (or hook = {a = "..."})	one serial (named) step
[hook] with ≥2 keys	one concurrent step
[[hook]] blocks	one step each, by the same rules

So a user who doesn't want concurrency simply never writes a multi-key map — the loader will never produce Concurrent on its own. That lines up with the user-facing docs: "Most hooks don't need [[hook]] blocks. Reach for them when there's a dependency chain — typically setup that must complete before later steps."

For interactive = true that's a clean fit: it's a per-Command field; if it appears on a step that parsed as Concurrent (i.e. a multi-key map), the loader rejects at config-load. Users who want a confirmation prompt write it as a serial step, which is the natural shape anyway — mise trust standalone, or one entry inside a [[pre-start]] block.

[endigma]

Would this also cover allowing interactive on post-x hooks so commands that expect to be run in the interactive shell would work there as well?

[worktrunk-bot]

Partly — pre-X and post-X hooks take different execution paths, so interactive = true would mean different things for each.

Pre-X hooks (pre-merge, pre-switch, pre-start, pre-commit, pre-remove): run in the foreground. There interactive = true is just the alias-shaped lever from earlier — flip pipe_stdin to false so the child inherits the parent's TTY (hooks.rs:591-596).

Post-X hooks (post-commit, post-merge, post-remove, post-switch): different path. They're spawned as detached background processes — spawn_hook_pipeline_quiet calls spawn_detached_exec (hooks.rs:540-548), which puts the child in its own process group with stdin(Stdio::null()) and stdout/stderr redirected to a log file in .git/wt/logs/ (process.rs:251-265). That split is policy, encoded in HookType::is_pre (git/mod.rs:499-509): pre-* block the operation and fail-fast; post-* run after success and default to background-with-warn.

So making post-X interactive isn't a stdin flip — it requires promoting them out of the detached path into a foreground-blocking pipeline, which is the same shape change you flagged earlier ("post-x being separate processes is a footgun"). Doable, but a bigger lift than the pre-X variant and with two visible-behavior consequences:

Implementation consequences

• Failure semantics flip. Today a failing post-merge logs and exits non-zero in the background, but wt merge itself has already returned success — the merge is done. Foreground-blocking inverts that: a failing interactive post-merge makes wt merge fail (exit code, scripts, CI) even though the actual merge committed. Probably the right tradeoff for an explicitly-opted-in step, but worth being deliberate about.
• --yes / non-TTY semantics. Same constraint as pre-X interactive: an interactive step under CommandContext::yes or a non-TTY stdin needs to either no-op the prompt or hard-fail, or wt merge --yes and CI deadlock. The cost is bigger here because today no post-X hook can deadlock CI — promoting them to foreground opens that door.
• Terminal hostage. The reason post-* detach is so your terminal returns immediately after wt merge. An interactive post-merge keeps the prompt; users opt in per-step, so this is fine — just naming it.

Worth being explicit about which post-hook the use case actually wants. mise trust in the original example is pre-start, which is the easy half. The post-X version (e.g. wanting direnv allow to prompt at the end of wt switch) is what needs the path change.

[max-sixty]

Shape Result
hook = "cmd" one serial step
hook = ["a", "b"] one serial step per item
[hook] with 1 key (or hook = {a = "..."}) one serial (named) step
[hook] with ≥2 keys one concurrent step
[[hook]] blocks one step each, by the same rules

@worktrunk-bot separate from the current issue, we gotta find a simpler way of expressing this. it's extremely complicated; I think in some ways needlessly (no need for 2nd item in the list, for example)

can we just say "each command in a hook block runs concurrently, so for serial execution. use multiple [[hook]] blocks; each block is run in turn"

how does that compare to our current docs?

[worktrunk-bot]

The 5-row table I posted above was for this thread, not from the docs — I was answering @endigma's "is there some constraint forcing some hooks to be concurrent?" by enumerating every TOML shape the deserializer sees. The docs themselves are closer to your wording than that table suggests.

Current docs/content/hook.md § Hook forms (source: src/cli/mod.rs:1310-1343):

Hooks take one of three forms, determined by their TOML shape.

A string is a single command: pre-start = "npm install"

A table is multiple commands that run concurrently: [post-start] + keys

A pipeline is a sequence of [[hook]] blocks run in order. Each block is one step; multiple keys within a block run concurrently. A failing step aborts the rest of the pipeline.

So the pipeline sentence is already very close to your proposed wording — "each block is one step; multiple keys within a block run concurrently" ≈ "each command in a hook block runs concurrently".

What your simpler framing does collapse is the table vs. pipeline distinction. Today the docs present them as two separate forms ([hook] section vs. [[hook]] array-of-tables), each with its own example. They're really the same idea — a block of commands run concurrently — with [[hook]] being the way to write more than one block. That collapse is a real win; reads as one concept instead of two.

Where it gets a little awkward is the single-command case (hook = "cmd"). "Each command in a block runs concurrently" implies a plural, so the string form still needs its own line as a shorthand. A draft along those lines:

Hooks take two forms.

A string is a single command: pre-start = "npm install".

A [[hook]] block is a step; if it lists multiple commands they run concurrently. Use multiple [[hook]] blocks for serial execution — each block runs in turn, and a failing block aborts the rest.

The [hook] (single-section) form still parses — that's the loader's job — but I'd stop documenting it as a third form and just lean on [[hook]] everywhere. Most users won't write either form; the string covers the common case.

On your "no need for 2nd item": agreed, and already true of the docs — hook = ["a", "b"] (anonymous list) parses but is intentionally undocumented. The code comment in src/config/commands.rs:168-175 says so explicitly: "Anonymous strings work but are intentionally undocumented — they complicate the explanation without adding much over single-entry maps." So the 5-row table was the implementation surface, not the documented surface — the docs already drop row 2.

Happy to open a PR if the draft above lands close to what you want.

[endigma]

This is getting a bit split into two concerns:

• foreground hooks should run interactively if selected (this ticket)

• post-x hooks maybe should be opt-in to not run in background processes (something else, would increase the value of this ticket's addition if the proposed interactive flag could also surface post-x tasks to the foreground)

I would suggest forking the issue, maybe @worktrunk-bot can handle making the second issue