Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a focused rework of the task execution runtime to support interactive tasks. It adds an interactive flag to task definitions, ensuring that such tasks run with direct TTY passthrough and exclusive access to the runtime via a read-write lock. This change allows for proper handling of interactive processes while maintaining the existing concurrency model for non-interactive tasks, providing a robust foundation for future interactive features.

Highlights

• Interactive Task Metadata: Introduced an interactive boolean metadata field for tasks, defaulting to false. This includes parsing from task models/headers and mise.toml, and integration into JSON schemas, mise tasks info --json, mise tasks ls --json, and the MCP mise://tasks payload.
• Global Async Runtime Lock: Implemented a global asynchronous runtime RwLock for task execution. Non-interactive tasks acquire a read lock, allowing concurrent execution, while interactive tasks acquire a write lock, ensuring exclusive execution.
• Interactive Runtime Behavior: Interactive tasks now require a TTY on stdin, use inherited stdio (stdin/stdout/stderr), preserve terminal restore behavior for raw/interactive command execution, and maintain PID tracking for consistent signal handling.
• Scheduler Alignment: The scheduler and --jobs behavior remain aligned with the current main branch, intentionally avoiding complex semaphore draining, barrier logic, or ticket ordering in this minimal rework.

Greptile Summary

This PR adds an interactive boolean task attribute that gives a task exclusive TTY access during execution, implemented via a new process-wide async TASK_RUNTIME_LOCK (tokio::sync::RwLock) in task_executor.rs: interactive tasks acquire a write lock (blocking all concurrent task commands), while non-interactive tasks acquire a read lock (allowing concurrency with each other). The executor-level lock composes with the pre-existing RAW_LOCK in cmd.rs, which serialises raw subprocess execution. Supporting changes include schema additions, JSON output fields (tasks info, tasks ls, MCP payload), task-file header parsing (#MISE interactive=true), and TTY state save/restore in execute_raw.

Key issues:

• The raw_redactions hint fires with an incorrect message "--raw will prevent mise from being able to use redactions" when interactive = true is set, because raw is eagerly set to true || self.raw(...) — but the user never passed --raw. The hint should either be gated on explicit --raw usage or the message should differentiate the interactive case.
• The pre_exec block calling setpgid(0, 0) in non-TTY contexts was moved from the non-raw execute() path to the raw execute_raw() path. This is a behavior change for existing --raw tasks: they now run in a new process group in non-TTY environments, potentially altering signal delivery semantics for CI workflows. The inline comment's rationale ("aligned with non-raw execution") is now unclear since non-raw execution no longer performs this setpgid call.

The core interactive lock semantics are sound and unit tests are well-structured with deterministic channel-based synchronization. However, both the user-facing hint message and the --raw task behavior change require clarification or fixes before merging.

Confidence Score: 2/5

• The core interactive lock semantics are sound, but two UX/documentation issues should be addressed: a misleading hint message and an unclear behavior change for existing --raw tasks.
• The PR implements the interactive lock feature correctly with well-designed tests and proper schema updates. However, two issues prevent confident merge: (1) The raw_redactions hint fires with an incorrect message --raw will prevent... when only interactive=true is set, misleading users about the cause. (2) The setpgid behavior in execute_raw() is a behavioral change for all raw tasks in non-TTY environments (CI), but the inline comment's rationale is unclear. Both issues require clarification or fixes. The core functionality is not broken, but these issues affect user experience and CI compatibility.
• src/task/task_executor.rs (misleading hint message) and src/cmd.rs (setpgid behavior change for --raw tasks)

Sequence Diagram

sequenceDiagram
    participant CLI as CLI (run.rs)
    participant Exec as TaskExecutor
    participant Lock as TASK_RUNTIME_LOCK<br/>(tokio RwLock)
    participant Cmd as CmdLineRunner
    participant RAW as RAW_LOCK<br/>(std RwLock)
    participant Child as Child Process

    Note over CLI,Child: Non-interactive task
    CLI->>Exec: exec_program(task.interactive=false)
    Exec->>Lock: acquire read lock
    Lock-->>Exec: read guard held
    Exec->>Cmd: execute() [raw=false]
    Cmd->>RAW: acquire read lock
    RAW-->>Cmd: read guard held
    Cmd->>Child: spawn + wait (piped I/O)
    Child-->>Cmd: exit
    Cmd-->>Exec: Ok(())
    Exec-->>CLI: Ok(())

    Note over CLI,Child: Interactive task
    CLI->>CLI: validate_task → is_terminal() check
    CLI->>Exec: exec_program(task.interactive=true)
    Exec->>Lock: acquire WRITE lock (blocks new readers)
    Lock-->>Exec: write guard held
    Exec->>Cmd: execute() [raw=true → execute_raw()]
    Cmd->>RAW: acquire WRITE lock
    RAW-->>Cmd: write guard held
    Cmd->>Child: pre_exec (setpgid if non-TTY) + spawn
    Note over Cmd: save TTY state (tcgetattr)
    Cmd->>Child: wait()
    Child-->>Cmd: exit
    Note over Cmd: restore TTY state (tcsetattr)
    Cmd-->>Exec: Ok(())
    Note over Exec: drop write guard → unblocks readers
    Exec-->>CLI: Ok(())

_{Last reviewed commit: b4acc27}

@greptileai review

@greptileai

The setpgid in execute_raw() is concerning given the history here.

We reverted setpgid entirely in #8347 because it caused hangs with nested mise tasks (Playwright killing a process group left grandchildren in separate groups alive, holding pipes open). The revert commit explicitly removed setpgid from all paths — both execute() and execute_raw().

This PR re-introduces setpgid(0, 0) into execute_raw() for non-TTY contexts. The problem is that execute_raw() is called for all raw tasks (--raw, settings.raw = true, and now interactive = true). So any raw = true task running in CI (non-TTY) will get the exact same setpgid behavior that was reverted in #8347, potentially re-introducing the Playwright-style hang.

The comment says "Keep raw-mode process group behavior aligned with non-raw execution in non-tty contexts" but the non-raw execute() path on main no longer does setpgid at all — it was removed in the revert.

My recommendation: drop the setpgid block entirely from this PR. The interactive feature doesn't need it — interactive tasks require a TTY by definition (there's an ensure!(is_terminal()) check), so the non-TTY setpgid branch would never even execute for interactive tasks. And for regular --raw tasks, re-introducing setpgid risks the same breakage we already reverted.

If there's a specific signal-handling problem that setpgid was meant to solve for interactive tasks, let's address it separately with a narrower fix that doesn't affect all raw tasks.

This comment was generated by Claude Code.

Thanks for scoping setpgid to self.interactive — that addresses the regression risk for existing --raw tasks.

However, there's still a logical issue: the setpgid is now dead code. Interactive tasks require a TTY (ensure!(is_terminal()) in both validate_task and exec_program), but the setpgid only fires when !is_terminal(). These conditions are mutually exclusive — if the task is interactive, we guaranteed stdin is a TTY, so the setpgid branch never executes.

I'd suggest just removing the setpgid block entirely. It can't fire for interactive tasks, and we've already established it shouldn't fire for regular raw tasks. Keeping dead code around process group manipulation is a footgun for future readers.

The TTY save/restore and PID tracking additions in execute_raw() look good and are useful regardless.

This comment was generated by Claude Code.

look just stop, it's clear to me you don't understand the code you're trying to write. We need to be very careful around this logic.

@jdx You're right about the setpgid — I had an automated fixup loop pushing without manual review on each iteration. That specific mistake is on me.

That said, I want to share some honest context on this whole process.

I've submitted 5 PRs over several weeks to fix a real regression — TTY tasks are broken since the scheduler rework, and this affects real workflows (ie: saml2aws → interactive tools in the same DAG). Each time, I got short feedback asking for something simpler, but without enough detail on what the target implementation should look like. I went from a static DAG planner, to a dynamic policy, to a semaphore barrier, to a segment RwLock — each one a genuine attempt to match what I understood you wanted.

I know TTYs, DAGs, and schedulers well. What I don't know well is the internal history of every code path in cmd.rs, and I didn't get enough direction to avoid these specific pitfalls. The setpgid/#8347 context wasn't something I could have inferred without guidance.

Since the implementation is this sensitive to internal context, I'd welcome you taking it from here. What matters most to me is fixing this TTY regression that affects your users (my team included).

I'm not going to argue about it but your PRs are the most slop I've ever received on this project.