• e2e/tasks/test_task_info
  • Updated expected JSON output to include the interactive field.
• e2e/tasks/test_task_ls
  • Updated expected JSON output for various task listings to include the interactive field.
• schema/mise-task.json
  • Added the interactive boolean property with a default value and description.
• schema/mise.json
  • Added the interactive boolean property to task definitions within the main schema.
• src/cli/mcp.rs
  • Modified the ServerHandler implementation to include the interactive task field in JSON responses.
• src/cli/tasks/info.rs
  • Updated the TasksInfo implementation to include the interactive task field in JSON output.
• src/cli/tasks/ls.rs
  • Updated the TasksLs implementation to include the interactive task field in JSON output.
• src/task/mod.rs
  • Added the interactive boolean field to the Task struct.
  • Updated parsing logic to read this field.
  • Set its default value.
  • Included it in a test example.
• src/task/task_executor.rs
  • Introduced a LazyLock<RwLock<()>> named TASK_RUNTIME_LOCK for managing concurrent task execution.
  • Modified the execute method to acquire a write lock for interactive tasks and a read lock for non-interactive tasks before command execution.
• src/task/task_output_handler.rs
  • Updated the raw method to consider tasks with interactive: true as raw for output handling.

• All unit tests (cargo test) passed.
• End-to-end tests for test_task_info and test_task_ls passed.
• mise run lint-fix passed.
• Manual testing confirmed that interactive tasks correctly acquire exclusive access while background tasks run in parallel.
• The pull request was generated with Claude Code.

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

1. src/task/task_executor.rs, line 329-332 (link)

   Read lock acquired before scripts run, delaying interactive tasks

   For non-interactive tasks (existing_guard = None, task.interactive = false), the read lock is acquired here — at the very start of exec_task_run_entries — before any script has actually started executing. If the task's first (and possibly only) entries are all RunEntry::SingleTask / RunEntry::TaskGroup, the read lock is acquired and then immediately set to None on the first loop iteration, creating a spurious window where the read lock is briefly held with no real work being done.

   More importantly, because the read lock is held across the entire consecutive-script sequence (not just per-script), an interactive task waiting for the write lock is blocked for the whole chain. By contrast, on the exec_file path for non-interactive tasks, the read lock is only acquired immediately before exec() and released as soon as exec() returns. This inconsistency means that a non-interactive task with many consecutive inline scripts blocks an interactive task much longer than a non-interactive file task doing the same amount of work.

   Consider acquiring the lock lazily (only when a RunEntry::Script is actually about to execute) and always releasing it between distinct script entries, rather than holding it from the top of the function:

   // Instead of acquiring upfront, start with no guard and acquire per-script:
   let mut guard: Option<RuntimeLockGuard<'static>> = match existing_guard {
       Some(g) => Some(g),  // interactive: keep the write-guard from confirm
       None => None,        // non-interactive: acquire lazily before each script
   };

2. src/task/task_executor.rs, line 635-639 (link)

   Redundant is_some check — simplify with or_else

   guard is either Some(write_lock) (interactive) or None (non-interactive). The if guard.is_some() { guard } else { … } pattern is equivalent to a simple or_else / unwrap_or_else:

   This also avoids wrapping the result in a redundant Option since the lock will always be acquired by this point — holding it in an Option obscures intent and won't trigger the must_use lint on RwLockWriteGuard.

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

3. src/task/task_executor.rs, line 704-718 (link)

   Interactive redactions hint silenced when raw = true is also set

   The hint branch condition task.interactive && !task.raw && !Settings::get().raw means that when a task has both interactive = true and raw = true, the condition is false and the user receives only the generic raw_redactions hint — with no mention that the interactive flag is also bypassing redactions. A user who later removes raw = true (thinking the hint only applied to raw) would silently lose the warning about redactions being bypassed.

   Consider checking task.interactive independently of whether raw was also set: