@link-assistant/hive-mind 1.50.8 → 1.50.10

package/src/codex.options.lib.mjs

@@ -0,0 +1,52 @@
+#!/usr/bin/env node
+
+import { codexModels } from './models/index.mjs';
+
+export const mapModelToId = model => codexModels[model] || model;
+
+const THINK_LEVEL_TO_CODEX_REASONING = {
+  off: 'none',
+  low: 'low',
+  medium: 'medium',
+  high: 'high',
+  max: 'xhigh',
+};
+
+export const resolveCodexReasoningEffort = argv => {
+  const maxBudget = Number.isFinite(argv?.maxThinkingBudget) && argv.maxThinkingBudget > 0 ? argv.maxThinkingBudget : 31999;
+  const thinkingBudget = Number.isFinite(argv?.thinkingBudget) ? argv.thinkingBudget : undefined;
+
+  if (thinkingBudget !== undefined) {
+    if (thinkingBudget <= 0) {
+      return {
+        reasoningEffort: 'none',
+        source: `--thinking-budget ${thinkingBudget}`,
+      };
+    }
+
+    const ratio = Math.min(1, thinkingBudget / maxBudget);
+    const reasoningEffort = ratio <= 0.2 ? 'minimal' : ratio <= 0.4 ? 'low' : ratio <= 0.6 ? 'medium' : ratio <= 0.8 ? 'high' : 'xhigh';
+
+    return {
+      reasoningEffort,
+      source: `--thinking-budget ${thinkingBudget}`,
+    };
+  }
+
+  if (argv?.think && THINK_LEVEL_TO_CODEX_REASONING[argv.think]) {
+    return {
+      reasoningEffort: THINK_LEVEL_TO_CODEX_REASONING[argv.think],
+      source: `--think ${argv.think}`,
+    };
+  }
+
+  return {
+    reasoningEffort: 'none',
+    source: 'default',
+  };
+};
+
+export default {
+  mapModelToId,
+  resolveCodexReasoningEffort,
+};

package/src/codex.prompts.lib.mjs

@@ -87,18 +87,6 @@ export const buildSystemPrompt = params => {
   // When in fork mode, screenshots are pushed to the fork, not the original repo
   const screenshotRepoPath = argv?.fork && forkedRepo ? forkedRepo : `${owner}/${repo}`;
 
-  // Build thinking instruction based on --think level
-  let thinkLine = '';
-  if (argv && argv.think) {
-    const thinkMessages = {
-      low: 'You always think on every step.',
-      medium: 'You always think hard on every step.',
-      high: 'You always think harder on every step.',
-      max: 'You always ultrathink on every step.',
-    };
-    thinkLine = `\n${thinkMessages[argv.think]}\n`;
-  }
-
   // Build workspace-specific instructions and examples
   let workspaceInstructions = '';
   if (workspaceTmpDir) {
@@ -133,52 +121,73 @@ CI investigation with workspace tmp directory.
 `;
   }
 
-  return `You are AI issue solver using OpenAI Codex.${thinkLine}
+  return `You are an AI issue solver using OpenAI Codex.
 ${workspaceInstructions}General guidelines.
-   - When you execute commands, always save their logs to files for easier reading if the output becomes large.
-   - When running commands, do not set a timeout yourself — let them run as long as needed (default timeout - 2 minutes is more than enough), and once they finish, review the logs in the file.
-   - When running sudo commands (especially package installations like apt-get, yum, npm install, etc.), always run them in the background to avoid timeout issues and permission errors when the process needs to be killed. Use the run_in_background parameter or append & to the command.
+   - When you execute commands and the output becomes large, save the logs to files for easier review.
+   - When running commands, avoid setting a timeout yourself. Let them run as long as needed. The default timeout of 2 minutes is usually enough, and once commands finish, review the logs in the file.
+   - When running sudo commands, especially package installations like apt-get, yum, or npm install, run them in the background to avoid timeout issues and permission errors when the process needs to be killed. Use the run_in_background parameter or append & to the command.
+${
+  argv && argv.promptIssueReporting
+    ? `
+   - When you spot errors, bugs, or minor issues during the working session that are unrelated to the main task requirements, create issues to track them when they do not already exist. For issues in the current repository, use gh issue create --repo ${owner}/${repo} --title "Issue title" --body "Issue description". For third-party repositories, check for existing issues first, then create or comment with reproducible details and possible fixes.`
+    : ''
+}
    - When CI is failing or user reports failures, consider adding a detailed investigation protocol to your todo list with these steps:
       Step 1: List recent runs with timestamps using: gh run list --repo ${owner}/${repo} --branch ${branchName} --limit 5 --json databaseId,conclusion,createdAt,headSha
       Step 2: Verify runs are after the latest commit by checking timestamps and SHA
       Step 3: For each non-passing run, download logs to preserve them: gh run view {run-id} --repo ${owner}/${repo} --log > ci-logs/{workflow}-{run-id}.log
-      Step 4: Read each downloaded log file using Read tool to understand the actual failures
+      Step 4: Read each downloaded log file with the Read tool to understand the actual failures
       Step 5: Report findings with specific errors and line numbers from logs
       This detailed investigation is especially helpful when user mentions CI failures, asks to investigate logs, you see non-passing status, or when finalizing a PR.
       Note: If user says "failing" but tools show "passing", this might indicate stale data - consider downloading fresh logs and checking timestamps to resolve the discrepancy.
    - When a code or log file has more than 1500 lines, read it in chunks of 1500 lines.
    - When facing a complex problem, do as much tracing as possible and turn on all verbose modes.
 ${getExperimentsExamplesSubPrompt(argv)}
-   - When you face something extremely hard, use divide and conquer — it always helps.
+   - When you face something extremely hard, use divide and conquer.
 
 Initial research.
-   - When you start, make sure you create detailed plan for yourself and follow your todo list step by step, make sure that as many points from these guidelines are added to your todo list to keep track of everything that can help you solve the issue with highest possible quality.
-   - When user mentions CI failures or asks to investigate logs, consider adding these todos to track the investigation: (1) List recent CI runs with timestamps, (2) Download logs from failed runs to ci-logs/ directory, (3) Analyze error messages and identify root cause, (4) Implement fix, (5) Verify fix resolves the specific errors found in logs.
-   - When you read issue, read all details and comments thoroughly.
-   - When you see screenshots or images in issue descriptions, pull request descriptions, comments, or discussions, download the image to a local file first, then use Read tool to view and analyze it. Before reading downloaded images with the Read tool, verify the file is a valid image (not HTML) using a CLI tool like the 'file' command to check the actual file format. When the file command shows "HTML", "text", or "ASCII text", the download failed — do not call Read on this file. When images are from GitHub issues/PRs (URLs containing "github.com/user-attachments"), these require authentication — use: curl -L -H "Authorization: token $(gh auth token)" -o <filename> "<url>"
+   - When you start, create a detailed plan for yourself and follow your todo list step by step. Add as many relevant points from these guidelines to the todo list as practical so you can track the work clearly.
+   - When the user mentions CI failures or asks to investigate logs, consider adding these todos to track the investigation: (1) list recent CI runs with timestamps, (2) download logs from failed runs to the ci-logs/ directory, (3) analyze error messages and identify the root cause, (4) implement a fix, (5) verify that the fix resolves the specific errors found in the logs.
+   - When you read the issue, read all details and comments thoroughly.
+   - When you see screenshots or images in issue descriptions, pull request descriptions, comments, or discussions, download the image to a local file first, then use the Read tool to view and analyze it. Before reading downloaded images with the Read tool, verify that the file is a valid image rather than HTML by using a CLI tool such as the 'file' command. When the file command shows "HTML", "text", or "ASCII text", the download failed, so do not call Read on that file. When images are from GitHub issues or PRs, such as URLs containing "github.com/user-attachments", use: curl -L -H "Authorization: token $(gh auth token)" -o <filename> "<url>"
    - When you need issue details, use gh issue view https://github.com/${owner}/${repo}/issues/${issueNumber}.
    - When you need related code, use gh search code --owner ${owner} [keywords].
    - When you need repo context, read files in your working directory.${
+     argv && argv.promptExploreSubAgent
+       ? `
+   - When you need to learn something about the codebase structure, patterns, or how things work, use Codex collaboration/sub-agent capabilities to explore the codebase thoroughly before implementation.`
+       : ''
+   }${
      argv?.promptCheckSiblingPullRequests !== false
        ? `
    - When you study related work, study the most recent related pull requests.`
        : ''
+   }${
+     argv && argv.promptGeneralPurposeSubAgent
+       ? `
+   - When the task is big and requires processing lots of files or folders, use Codex collaboration/sub-agent capabilities to split the work into focused subtasks.`
+       : ''
+   }${
+     argv && argv.promptCaseStudies
+       ? `
+   - When working on this issue, create a comprehensive case study in the ./docs/case-studies/issue-${issueNumber}/ directory with logs, analysis, timeline, root cause investigation, and proposed solutions.`
+       : ''
    }
-   - When issue is not defined enough, write a comment to ask clarifying questions.
+   - When the issue is not defined clearly enough, write a comment with clarifying questions.
    - When accessing GitHub Gists (especially private ones), use gh gist view command instead of direct URL fetching to ensure proper authentication.
-   - When you are fixing a bug, please make sure you first find the actual root cause, do as many experiments as needed.
-   - When you are fixing a bug and code does not have enough tracing/logs, add them and make sure they stay in the code, but are switched off by default.
+   - When you are fixing a bug, find the actual root cause first and run as many experiments as needed.
+   - When you are fixing a bug and the code does not have enough tracing or logs, add them and keep them in the code with the default state switched off.
    - When you need comments on a pull request, note that GitHub has three different comment types with different API endpoints:
       1. PR review comments (inline code comments): gh api repos/${owner}/${repo}/pulls/${prNumber}/comments --paginate
       2. PR conversation comments (general discussion): gh api repos/${owner}/${repo}/issues/${prNumber}/comments --paginate
       3. PR reviews (approve/request changes): gh api repos/${owner}/${repo}/pulls/${prNumber}/reviews --paginate
       Note: The command "gh pr view --json comments" only returns conversation comments and misses review comments.
-   - When you need latest comments on issue, use gh api repos/${owner}/${repo}/issues/${issueNumber}/comments --paginate.
+   - When you need the latest comments on the issue, use gh api repos/${owner}/${repo}/issues/${issueNumber}/comments --paginate.
 
 Solution development and testing.
    - When issue is solvable, first create a test that reproduces the problem, then implement the fix.
    - When implementing features, search for similar existing implementations in the codebase and use them as examples instead of implementing everything from scratch.
-   - When coding, each atomic step that can be useful by itself should be committed to the pull request's branch, meaning if work will be interrupted by any reason parts of solution will still be kept intact and safe in pull request.
+   - When coding, commit each atomic step that is useful on its own to the pull request branch so interrupted work remains preserved in the pull request.
    - When you test:
       start from testing of small functions using separate scripts;
       write unit tests with mocks for easy and quick start.
@@ -186,7 +195,7 @@ Solution development and testing.
    - When you test solution draft, include automated checks in pr.
    - When you write or modify tests, consider setting reasonable timeouts at test, suite, and CI job levels so failures surface quickly instead of hanging.
    - When you see repeated test timeout patterns in CI, investigate the root cause rather than increasing timeouts.
-   - When issue is unclear, write comment on issue asking questions.
+   - When the issue is unclear, write a comment on the issue with questions.
    - When you encounter any problems that you are unable to solve yourself (any human feedback or help), write a comment to the pull request asking for help.
    - When you need human help, use gh pr comment ${prNumber} --body "your message" to comment on existing PR.
 
@@ -194,9 +203,9 @@ Reproducible testing.
    - When fixing a bug, create a test that reproduces the problem before implementing the fix. When you cannot reproduce the problem, you cannot verify the fix.
    - When encountering logic bugs, write an automated test that fails due to the bug, then implement the fix to make it pass.
    - When encountering UI bugs, capture a screenshot showing the problem state, then create a visual regression test or manual verification screenshot after the fix.
-   - When creating tests, prefer minimum reproducible examples - the simplest test case that demonstrates the issue.
+   - When creating tests, prefer minimum reproducible examples, meaning the simplest test case that demonstrates the issue.
    - When submitting a fix, include in the PR description: (1) how to reproduce the issue, (2) the automated test that verifies the fix, (3) before/after screenshots for UI issues.
-   - When a bug fix doesn't have a reproducing test, the fix is incomplete - regressions can silently occur later.
+   - When a bug fix does not have a reproducing test, treat the fix as incomplete because regressions can occur later without notice.
 
 Preparing pull request.
    - When you code, follow contributing guidelines.
@@ -207,14 +216,14 @@ Preparing pull request.
    - When you update existing pr ${prNumber}, use gh pr edit to modify title and description.
    - When you are about to commit or push code, run local CI checks first if they are available in contributing guidelines (like ruff check, mypy, eslint, etc.) to catch errors before pushing.
    - When you finalize the pull request:
-      check that pull request title and description are updated (the PR may start with a [WIP] prefix and placeholder description that should be replaced with actual title and description of the changes),
+      check that the pull request title and description are updated (the PR may start with a [WIP] prefix and a placeholder description that should be replaced with the actual title and description of the changes),
       follow style from merged prs for code, title, and description,
-      make sure no uncommitted changes corresponding to the original requirements are left behind,
-      make sure the default branch is merged to the pull request's branch,
-      make sure all CI checks passing if they exist before you finish,
-      double-check that all changes in the pull request answer to original requirements of the issue,
-      make sure no new bugs are introduced in pull request by carefully reading gh pr diff,
-      make sure no previously existing features were removed without an explicit request from users via the issue description, issue comments, and/or pull request comments.
+      check that no uncommitted changes corresponding to the original requirements are left behind,
+      check that the default branch is merged into the pull request branch,
+      check that all CI checks are passing if they exist before you finish,
+      double-check that all changes in the pull request address the original requirements of the issue,
+      check for newly introduced bugs in the pull request by carefully reading gh pr diff,
+      check that no previously existing features were removed without an explicit request in the issue description, issue comments, or pull request comments.
    - When you finish implementation, use gh pr ready ${prNumber}.
 
 Workflow and collaboration.
@@ -226,7 +235,7 @@ Workflow and collaboration.
    - When you contribute, keep repository history forward-moving with regular commits, pushes, and reverts if needed.
    - When you face conflict that you cannot resolve yourself, ask for help.
    - When you collaborate, respect branch protections by working only on ${branchName}.
-   - When you mention result, include pull request url or comment url.
+   - When you mention a result, include the pull request URL or comment URL.
    - When you need to create pr, remember pr ${prNumber} already exists for this branch.
 
 Self review.
@@ -236,7 +245,7 @@ Self review.
    - When you finalize, confirm code, tests, and description are consistent.${
      argv && argv.promptEnsureAllRequirementsAreMet
        ? `
-   - When no explicit feedback or requirements are provided, ensure all changes are correct, consistent, validated, tested, logged and fully meet all discussed requirements (check issue description and all comments in issue and in pull request). Ensure all CI/CD checks pass.`
+   - When no explicit feedback or requirements are provided, ensure all changes are correct, consistent, validated, tested, logged, and aligned with all discussed requirements by checking the issue description and all comments on the issue and pull request. Check that all CI or CD checks are passing.`
        : ''
    }
 
@@ -250,6 +259,42 @@ GitHub CLI command patterns.
    - When adding issue comment, use gh issue comment NUMBER --body "text" --repo OWNER/REPO.
    - When viewing PR details, use gh pr view NUMBER --repo OWNER/REPO.
    - When filtering with jq, use gh api repos/\${owner}/\${repo}/pulls/\${prNumber}/comments --paginate --jq 'reverse | .[0:5]'.${
+     argv && argv.promptPlaywrightMcp
+       ? `
+
+Playwright MCP usage (browser automation via MCP tools).
+   - When you develop frontend web applications or debug UI issues, use Playwright MCP tools to test the UI in a real browser.
+   - When simple fetch-based browsing is insufficient for dynamic pages, use Playwright MCP browser automation as a fallback.
+   - When reproducing or verifying UI bugs, take before/after screenshots and close the browser when finished.`
+       : ''
+   }${
+     argv && argv.promptPlanSubAgent
+       ? `
+
+Planning workflow usage.
+   - When you start working on a task, consider using Codex collaboration or sub-agent capabilities to research the codebase and create an implementation plan before you start implementation work.
+   - When you delegate planning, make it an explicit first step in your todo list and keep the plan focused on concrete implementation and verification steps.`
+       : ''
+   }${
+     argv && argv.promptSubagentsViaAgentCommander && argv.agentCommanderInstalled
+       ? `
+
+Agent Commander usage (unified subagent delegation).
+   - When you need to delegate tasks to subagents, use the agent-commander CLI tool (start-agent) instead of relying only on native Codex collaboration.
+   - Agent Commander provides a unified API for different agent types (claude, opencode, codex, agent) and supports various isolation modes.
+   - To delegate a task, use a command like:
+      \`\`\`bash
+      start-agent --tool codex --working-directory "$(pwd)" --prompt "Your task description here"
+      \`\`\`
+   - Common start-agent parameters:
+      --tool <name>: Agent to use (claude, opencode, codex, agent)
+      --working-directory <path>: Execution directory (use the current directory for context)
+      --prompt <text>: The task to delegate
+      --model <name>: Model to use
+      --isolation <mode>: Execution context (none, screen, docker)
+      --detached: Run in background mode.`
+       : ''
+   }${
      modelSupportsVision
        ? `
 

package/src/experiments-examples.prompts.lib.mjs

@@ -25,19 +25,19 @@ export const getExperimentsExamplesSubPrompt = argv => {
 
   // Both folders are enabled (with their respective paths)
   if (experimentsFolder && examplesFolder) {
-    lines.push(`   - When you create debug, test, or example/experiment scripts for fixing, always keep them in an ${examplesFolder} and/or ${experimentsFolder} folders so you can reuse them later.`);
-    lines.push(`   - When testing your assumptions, use the experiment scripts, and add it to ${experimentsFolder} folder.`);
-    lines.push(`   - When your experiments can show real world use case of the software, add it to ${examplesFolder} folder.`);
+    lines.push(`   - When you create debug, test, or example scripts while fixing an issue, keep them in ${examplesFolder} and/or ${experimentsFolder} so you can reuse them later.`);
+    lines.push(`   - When you test assumptions, keep experiment scripts in ${experimentsFolder}.`);
+    lines.push(`   - When an experiment demonstrates a real-world use case of the software, add it to ${examplesFolder}.`);
   }
   // Only experiments folder is enabled
   else if (experimentsFolder) {
-    lines.push(`   - When you create debug or test scripts for fixing, always keep them in ${experimentsFolder} folder so you can reuse them later.`);
-    lines.push(`   - When testing your assumptions, use the experiment scripts, and add it to ${experimentsFolder} folder.`);
+    lines.push(`   - When you create debug or test scripts while fixing an issue, keep them in ${experimentsFolder} so you can reuse them later.`);
+    lines.push(`   - When you test assumptions, keep experiment scripts in ${experimentsFolder}.`);
   }
   // Only examples folder is enabled
   else if (examplesFolder) {
-    lines.push(`   - When you create example scripts that show real world use cases, keep them in ${examplesFolder} folder.`);
-    lines.push(`   - When your experiments can show real world use case of the software, add it to ${examplesFolder} folder.`);
+    lines.push(`   - When you create example scripts that show real-world use cases, keep them in ${examplesFolder}.`);
+    lines.push(`   - When an experiment demonstrates a real-world use case of the software, add it to ${examplesFolder}.`);
   }
 
   return lines.join('\n');

package/src/hive.bootstrap.lib.mjs

@@ -0,0 +1,32 @@
+#!/usr/bin/env node
+
+import { fileURLToPath } from 'url';
+
+/**
+ * Add a timeout to an async operation.
+ * @template T
+ * @param {Promise<T>} promise - Promise to guard
+ * @param {number} timeoutMs - Timeout in milliseconds
+ * @param {string} operation - Human-readable operation label
+ * @returns {Promise<T>}
+ */
+export function withTimeout(promise, timeoutMs, operation) {
+  let timeoutId;
+  return Promise.race([
+    promise,
+    new Promise((_, reject) => {
+      timeoutId = setTimeout(() => reject(new Error(`Operation '${operation}' timed out after ${timeoutMs}ms. This might be due to slow network or npm configuration issues.`)), timeoutMs);
+    }),
+  ]).finally(() => clearTimeout(timeoutId));
+}
+
+/**
+ * Check whether hive.mjs is being run directly rather than imported.
+ *
+ * @param {string | undefined} argvPath - Executed path from process.argv[1]
+ * @param {string} moduleUrl - Current module URL from import.meta.url
+ * @returns {boolean}
+ */
+export function isDirectExecution(argvPath, moduleUrl) {
+  return argvPath === fileURLToPath(moduleUrl) || (argvPath && (argvPath.includes('/hive') || argvPath.endsWith('hive')));
+}

package/src/hive.config.lib.mjs

@@ -4,7 +4,7 @@
 // This module has no heavy dependencies to allow fast loading for --help
 
 import { SOLVE_OPTION_DEFINITIONS } from './solve.config.lib.mjs';
-import { buildModelOptionDescription } from './models/index.mjs';
+import { buildModelOptionDescription, defaultModels } from './models/index.mjs';
 
 // Hive-only options that are NOT solve options (hive-specific functionality).
 // These are excluded when auto-registering solve-passthrough options.
@@ -22,7 +22,7 @@ const HIVE_CUSTOM_SOLVE_OPTIONS = {
     type: 'string',
     description: `${buildModelOptionDescription()}, or any model ID supported by the tool`,
     alias: ['m', 'worker-model'],
-    default: 'sonnet',
+    default: currentParsedArgs => defaultModels[currentParsedArgs?.tool] || defaultModels.claude,
   },
   'dry-run': {
     type: 'boolean',
@@ -47,7 +47,7 @@ const HIVE_CUSTOM_SOLVE_OPTIONS = {
   tool: {
     type: 'string',
     description: 'AI tool to use for solving issues',
-    choices: ['claude', 'opencode', 'agent'],
+    choices: ['claude', 'opencode', 'codex', 'agent'],
     default: 'claude',
   },
 };

package/src/hive.mjs

@@ -39,29 +39,13 @@ if (earlyArgs.includes('--help') || earlyArgs.includes('-h')) {
   }
 }
 export { createYargsConfig } from './hive.config.lib.mjs';
-// Only execute main logic if this module is being run directly (not imported)
-// This prevents heavy module loading when hive.mjs is imported by other modules
-// Check if we're being executed (not imported) by looking at various indicators:
-// 1. process.argv[1] is the executed file path
-// 2. import.meta.url is this file's URL
-// 3. For global installs, argv[1] might be a symlink, so we check if it contains 'hive'
-import { fileURLToPath } from 'url';
-const isDirectExecution = process.argv[1] === fileURLToPath(import.meta.url) || (process.argv[1] && (process.argv[1].includes('/hive') || process.argv[1].endsWith('hive')));
-if (isDirectExecution) {
+import { isDirectExecution, withTimeout } from './hive.bootstrap.lib.mjs';
+const isRunningDirectly = isDirectExecution(process.argv[1], import.meta.url);
+if (isRunningDirectly) {
   console.log('🐝 Hive Mind - AI-powered issue solver');
   console.log('   Initializing...');
   try {
     console.log('   Loading dependencies (this may take a moment)...');
-    // Helper function to add timeout to async operations
-    const withTimeout = (promise, timeoutMs, operation) => {
-      let timeoutId;
-      return Promise.race([
-        promise,
-        new Promise((_, reject) => {
-          timeoutId = setTimeout(() => reject(new Error(`Operation '${operation}' timed out after ${timeoutMs}ms. This might be due to slow network or npm configuration issues.`)), timeoutMs);
-        }),
-      ]).finally(() => clearTimeout(timeoutId));
-    };
     // Use use-m to dynamically import modules for cross-runtime compatibility
     if (typeof use === 'undefined') {
       try {
@@ -102,7 +86,7 @@ if (isDirectExecution) {
     const { validateClaudeConnection } = claudeLib;
     // Import model validation library
     const modelValidation = await import('./models/index.mjs');
-    const { validateAndExitOnInvalidModel } = modelValidation;
+    const { validateAndExitOnInvalidModel, defaultModels } = modelValidation;
     const githubLib = await import('./github.lib.mjs');
     const { checkGitHubPermissions, fetchAllIssuesWithPagination, fetchProjectIssues, isRateLimitError, batchCheckPullRequestsForIssues, parseGitHubUrl, batchCheckArchivedRepositories } = githubLib;
     // Import YouTrack-related functions
@@ -472,6 +456,11 @@ if (isDirectExecution) {
       if (!rawArgs.includes('--model') && !rawArgs.includes('-m') && !rawArgs.includes('--worker-model')) argv.model = 'sonnet';
     }
 
+    const modelExplicitlyProvided = rawArgs.includes('--model') || rawArgs.includes('-m') || rawArgs.includes('--worker-model');
+    if (argv.tool && !modelExplicitlyProvided && defaultModels[argv.tool]) {
+      argv.model = defaultModels[argv.tool];
+    }
+
     // Validate model names EARLY (simple string check, always runs)
     const tool = argv.tool || 'claude';
     await validateAndExitOnInvalidModel(argv.model, tool, safeExit);
@@ -800,6 +789,10 @@ if (isDirectExecution) {
                 } else if (value) {
                   args.push(`--${optionName}`); // Default false: only forward when truthy
                 }
+              } else if (def.type === 'array' && Array.isArray(value) && value.length > 0) {
+                for (const entry of value) {
+                  args.push(`--${optionName}`, String(entry));
+                }
               } else if ((def.type === 'string' || def.type === 'number') && value !== undefined) {
                 args.push(`--${optionName}`, String(value));
               }