bug: `mise run cluster` fails on macOS — `mapfile` requires bash 4+

[raktes]

Agent Diagnostic

• Ran mise run cluster on macOS (Apple Silicon, Darwin 25.2.0)
• Script failed at tasks/scripts/cluster-deploy-fast.sh:91 with mapfile: command not found
• Confirmed /bin/bash --version is GNU bash, version 3.2.57(1)-release (arm64-apple-darwin25) — macOS ships bash 3.2 which lacks the mapfile builtin (added in bash 4.0)
• Grepped for other mapfile usages: this is the only occurrence in the codebase
• The same script already uses the portable while IFS= read -r pattern at line 108, confirming the fix is consistent with existing code
• Searched OpenShell issues for mapfile, bash, macos cluster — no existing report found
• Fix verified: replacing mapfile -t with while read loop resolves the issue on bash 3.2 and remains compatible with bash 4+/5+ on Linux

Source: Bash FAQ #005, Bash Pitfalls #56

Description

mise run cluster fails on macOS because tasks/scripts/cluster-deploy-fast.sh line 91 uses mapfile -t, a bash 4.0+ builtin. macOS ships bash 3.2.57 (stuck at 3.2 since 2007 due to GPLv3 licensing). No homebrew bash is required for any other part of the project.

Expected: mise run cluster succeeds on macOS with the default system bash.
Actual: Fails with mapfile: command not found.

Reproduction Steps

1. macOS with default /bin/bash (3.2), no homebrew bash installed
2. Clone repo, install mise tools
3. mise run cluster
4. Observe: tasks/scripts/cluster-deploy-fast.sh: line 91: mapfile: command not found

Environment

• OS: macOS 15.5 (Darwin 25.2.0), Apple Silicon (arm64)
• Docker: Docker Desktop
• OpenShell: built from main (commit b7779bd)
• Bash: /bin/bash 3.2.57(1)-release

Logs

[cluster] $ tasks/scripts/cluster.sh
/Users/.../openshell/tasks/scripts/cluster-deploy-fast.sh: line 91: mapfile: command not found
[cluster] ERROR task failed

Proposed Fix

Replace the single mapfile call with the portable while read pattern already used elsewhere in the same script:

# Before (line 91, bash 4+ only):
mapfile -t changed_files < <(
  {
    git diff --name-only
    git diff --name-only --cached
    git ls-files --others --exclude-standard
  } | sort -u
)

# After (bash 3.2+ compatible):
while IFS= read -r line; do
  changed_files+=("$line")
done < <(
  {
    git diff --name-only
    git diff --name-only --cached
    git ls-files --others --exclude-standard
  } | sort -u
)

This is a universal fix — works on both macOS bash 3.2 and Linux bash 5.x.

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., debug-openshell-cluster, debug-inference, openshell-cli)
• My agent could not resolve this — the diagnostic above explains why

[github-actions]

This issue appears to have been opened without an agent investigation.

OpenShell is an agent-first project - please point your coding agent at the repo and have it diagnose this before we triage. Your agent can load skills like debug-openshell-cluster, debug-inference, openshell-cli, and generate-sandbox-policy.

See CONTRIBUTING.md for the full workflow.

[raktes]

Additional mapfile occurrences

After further testing, two more mapfile calls were found in scripts/bin/openshell (the dev auto-rebuild CLI wrapper):

• Line 29: mapfile -t changed_files < <(...) — collects dirty files for rebuild detection
• Line 98: mapfile -t post_files < <(...) — recomputes fingerprint after build

Same fix applies — replace with while IFS= read -r line; do arr+=("$line"); done < <(...).

Additional bash 3.2 issue

tasks/scripts/sandbox.sh line 101 uses ${PROVIDER_ARGS[@]} under set -u, which triggers "unbound variable" when the array is empty. Bash 3.2 doesn't support ${arr[@]} on empty arrays with strict mode. Fix: ${PROVIDER_ARGS[@]+"${PROVIDER_ARGS[@]}"}.

Why this only surfaces on incremental redeploys

The mapfile in cluster-deploy-fast.sh is only reached when cluster.sh detects an existing healthy cluster and takes the incremental deploy path. A fresh bootstrap (cluster-bootstrap.sh) doesn't use mapfile, which is why first-time mise run sandbox succeeds on macOS. The bug only appears on subsequent runs when the cluster container already exists.

Total occurrences: 3 mapfile calls + 1 unbound array expansion, across 3 files.