@iaforged/context-code 1.0.59 → 1.0.62

package/dist/src/tools/TeamCreateTool/prompt.js

@@ -1,113 +1,113 @@
 export function getPrompt() {
-    return `
-# TeamCreate
-
-## When to Use
-
-Use this tool proactively whenever:
-- The user explicitly asks to use a team, swarm, or group of agents
-- The user mentions wanting agents to work together, coordinate, or collaborate
-- A task is complex enough that it would benefit from parallel work by multiple agents (e.g., building a full-stack feature with frontend and backend work, refactoring a codebase while keeping tests passing, implementing a multi-step project with research, planning, and coding phases)
-
-When in doubt about whether a task warrants a team, prefer spawning a team.
-
-## Choosing Agent Types for Teammates
-
-When spawning teammates via the Agent tool, choose the \`subagent_type\` based on what tools the agent needs for its task. Each agent type has a different set of available tools — match the agent to the work:
-
-- **Read-only agents** (e.g., Explore, Plan) cannot edit or write files. Only assign them research, search, or planning tasks. Never assign them implementation work.
-- **Full-capability agents** (e.g., general-purpose) have access to all tools including file editing, writing, and bash. Use these for tasks that require making changes.
-- **Custom agents** defined in \`.claude/agents/\` may have their own tool restrictions. Check their descriptions to understand what they can and cannot do.
-
-Always review the agent type descriptions and their available tools listed in the Agent tool prompt before selecting a \`subagent_type\` for a teammate.
-
-Create a new team to coordinate multiple agents working on a project. Teams have a 1:1 correspondence with task lists (Team = TaskList).
-
-\`\`\`
-{
-  "team_name": "my-project",
-  "description": "Working on feature X"
-}
-\`\`\`
-
-This creates:
-- A team file at \`~/.claude/teams/{team-name}/config.json\`
-- A corresponding task list directory at \`~/.claude/tasks/{team-name}/\`
-
-## Team Workflow
-
-1. **Create a team** with TeamCreate - this creates both the team and its task list
-2. **Create tasks** using the Task tools (TaskCreate, TaskList, etc.) - they automatically use the team's task list
-3. **Spawn teammates** using the Agent tool with \`team_name\` and \`name\` parameters to create teammates that join the team
-4. **Assign tasks** using TaskUpdate with \`owner\` to give tasks to idle teammates
-5. **Teammates work on assigned tasks** and mark them completed via TaskUpdate
-6. **Teammates go idle between turns** - after each turn, teammates automatically go idle and send a notification. IMPORTANT: Be patient with idle teammates! Don't comment on their idleness until it actually impacts your work.
-7. **Shutdown your team** - when the task is completed, gracefully shut down your teammates via SendMessage with \`message: {type: "shutdown_request"}\`.
-
-## Task Ownership
-
-Tasks are assigned using TaskUpdate with the \`owner\` parameter. Any agent can set or change task ownership via TaskUpdate.
-
-## Automatic Message Delivery
-
-**IMPORTANT**: Messages from teammates are automatically delivered to you. You do NOT need to manually check your inbox.
-
-When you spawn teammates:
-- They will send you messages when they complete tasks or need help
-- These messages appear automatically as new conversation turns (like user messages)
-- If you're busy (mid-turn), messages are queued and delivered when your turn ends
-- The UI shows a brief notification with the sender's name when messages are waiting
-
-Messages will be delivered automatically.
-
-When reporting on teammate messages, you do NOT need to quote the original message—it's already rendered to the user.
-
-## Teammate Idle State
-
-Teammates go idle after every turn—this is completely normal and expected. A teammate going idle immediately after sending you a message does NOT mean they are done or unavailable. Idle simply means they are waiting for input.
-
-- **Idle teammates can receive messages.** Sending a message to an idle teammate wakes them up and they will process it normally.
-- **Idle notifications are automatic.** The system sends an idle notification whenever a teammate's turn ends. You do not need to react to idle notifications unless you want to assign new work or send a follow-up message.
-- **Do not treat idle as an error.** A teammate sending a message and then going idle is the normal flow—they sent their message and are now waiting for a response.
-- **Peer DM visibility.** When a teammate sends a DM to another teammate, a brief summary is included in their idle notification. This gives you visibility into peer collaboration without the full message content. You do not need to respond to these summaries — they are informational.
-
-## Discovering Team Members
-
-Teammates can read the team config file to discover other team members:
-- **Team config location**: \`~/.claude/teams/{team-name}/config.json\`
-
-The config file contains a \`members\` array with each teammate's:
-- \`name\`: Human-readable name (**always use this** for messaging and task assignment)
-- \`agentId\`: Unique identifier (for reference only - do not use for communication)
-- \`agentType\`: Role/type of the agent
-
-**IMPORTANT**: Always refer to teammates by their NAME (e.g., "team-lead", "researcher", "tester"). Names are used for:
-- \`to\` when sending messages
-- Identifying task owners
-
-Example of reading team config:
-\`\`\`
-Use the Read tool to read ~/.claude/teams/{team-name}/config.json
-\`\`\`
-
-## Task List Coordination
-
-Teams share a task list that all teammates can access at \`~/.claude/tasks/{team-name}/\`.
-
-Teammates should:
-1. Check TaskList periodically, **especially after completing each task**, to find available work or see newly unblocked tasks
-2. Claim unassigned, unblocked tasks with TaskUpdate (set \`owner\` to your name). **Prefer tasks in ID order** (lowest ID first) when multiple tasks are available, as earlier tasks often set up context for later ones
-3. Create new tasks with \`TaskCreate\` when identifying additional work
-4. Mark tasks as completed with \`TaskUpdate\` when done, then check TaskList for next work
-5. Coordinate with other teammates by reading the task list status
-6. If all available tasks are blocked, notify the team lead or help resolve blocking tasks
-
-**IMPORTANT notes for communication with your team**:
-- Do not use terminal tools to view your team's activity; always send a message to your teammates (and remember, refer to them by name).
-- Your team cannot hear you if you do not use the SendMessage tool. Always send a message to your teammates if you are responding to them.
-- Do NOT send structured JSON status messages like \`{"type":"idle",...}\` or \`{"type":"task_completed",...}\`. Just communicate in plain text when you need to message teammates.
-- Use TaskUpdate to mark tasks completed.
-- If you are an agent in the team, the system will automatically send idle notifications to the team lead when you stop.
-
+    return `
+# TeamCreate
+
+## When to Use
+
+Use this tool proactively whenever:
+- The user explicitly asks to use a team, swarm, or group of agents
+- The user mentions wanting agents to work together, coordinate, or collaborate
+- A task is complex enough that it would benefit from parallel work by multiple agents (e.g., building a full-stack feature with frontend and backend work, refactoring a codebase while keeping tests passing, implementing a multi-step project with research, planning, and coding phases)
+
+When in doubt about whether a task warrants a team, prefer spawning a team.
+
+## Choosing Agent Types for Teammates
+
+When spawning teammates via the Agent tool, choose the \`subagent_type\` based on what tools the agent needs for its task. Each agent type has a different set of available tools — match the agent to the work:
+
+- **Read-only agents** (e.g., Explore, Plan) cannot edit or write files. Only assign them research, search, or planning tasks. Never assign them implementation work.
+- **Full-capability agents** (e.g., general-purpose) have access to all tools including file editing, writing, and bash. Use these for tasks that require making changes.
+- **Custom agents** defined in \`.claude/agents/\` may have their own tool restrictions. Check their descriptions to understand what they can and cannot do.
+
+Always review the agent type descriptions and their available tools listed in the Agent tool prompt before selecting a \`subagent_type\` for a teammate.
+
+Create a new team to coordinate multiple agents working on a project. Teams have a 1:1 correspondence with task lists (Team = TaskList).
+
+\`\`\`
+{
+  "team_name": "my-project",
+  "description": "Working on feature X"
+}
+\`\`\`
+
+This creates:
+- A team file at \`~/.claude/teams/{team-name}/config.json\`
+- A corresponding task list directory at \`~/.claude/tasks/{team-name}/\`
+
+## Team Workflow
+
+1. **Create a team** with TeamCreate - this creates both the team and its task list
+2. **Create tasks** using the Task tools (TaskCreate, TaskList, etc.) - they automatically use the team's task list
+3. **Spawn teammates** using the Agent tool with \`team_name\` and \`name\` parameters to create teammates that join the team
+4. **Assign tasks** using TaskUpdate with \`owner\` to give tasks to idle teammates
+5. **Teammates work on assigned tasks** and mark them completed via TaskUpdate
+6. **Teammates go idle between turns** - after each turn, teammates automatically go idle and send a notification. IMPORTANT: Be patient with idle teammates! Don't comment on their idleness until it actually impacts your work.
+7. **Shutdown your team** - when the task is completed, gracefully shut down your teammates via SendMessage with \`message: {type: "shutdown_request"}\`.
+
+## Task Ownership
+
+Tasks are assigned using TaskUpdate with the \`owner\` parameter. Any agent can set or change task ownership via TaskUpdate.
+
+## Automatic Message Delivery
+
+**IMPORTANT**: Messages from teammates are automatically delivered to you. You do NOT need to manually check your inbox.
+
+When you spawn teammates:
+- They will send you messages when they complete tasks or need help
+- These messages appear automatically as new conversation turns (like user messages)
+- If you're busy (mid-turn), messages are queued and delivered when your turn ends
+- The UI shows a brief notification with the sender's name when messages are waiting
+
+Messages will be delivered automatically.
+
+When reporting on teammate messages, you do NOT need to quote the original message—it's already rendered to the user.
+
+## Teammate Idle State
+
+Teammates go idle after every turn—this is completely normal and expected. A teammate going idle immediately after sending you a message does NOT mean they are done or unavailable. Idle simply means they are waiting for input.
+
+- **Idle teammates can receive messages.** Sending a message to an idle teammate wakes them up and they will process it normally.
+- **Idle notifications are automatic.** The system sends an idle notification whenever a teammate's turn ends. You do not need to react to idle notifications unless you want to assign new work or send a follow-up message.
+- **Do not treat idle as an error.** A teammate sending a message and then going idle is the normal flow—they sent their message and are now waiting for a response.
+- **Peer DM visibility.** When a teammate sends a DM to another teammate, a brief summary is included in their idle notification. This gives you visibility into peer collaboration without the full message content. You do not need to respond to these summaries — they are informational.
+
+## Discovering Team Members
+
+Teammates can read the team config file to discover other team members:
+- **Team config location**: \`~/.claude/teams/{team-name}/config.json\`
+
+The config file contains a \`members\` array with each teammate's:
+- \`name\`: Human-readable name (**always use this** for messaging and task assignment)
+- \`agentId\`: Unique identifier (for reference only - do not use for communication)
+- \`agentType\`: Role/type of the agent
+
+**IMPORTANT**: Always refer to teammates by their NAME (e.g., "team-lead", "researcher", "tester"). Names are used for:
+- \`to\` when sending messages
+- Identifying task owners
+
+Example of reading team config:
+\`\`\`
+Use the Read tool to read ~/.claude/teams/{team-name}/config.json
+\`\`\`
+
+## Task List Coordination
+
+Teams share a task list that all teammates can access at \`~/.claude/tasks/{team-name}/\`.
+
+Teammates should:
+1. Check TaskList periodically, **especially after completing each task**, to find available work or see newly unblocked tasks
+2. Claim unassigned, unblocked tasks with TaskUpdate (set \`owner\` to your name). **Prefer tasks in ID order** (lowest ID first) when multiple tasks are available, as earlier tasks often set up context for later ones
+3. Create new tasks with \`TaskCreate\` when identifying additional work
+4. Mark tasks as completed with \`TaskUpdate\` when done, then check TaskList for next work
+5. Coordinate with other teammates by reading the task list status
+6. If all available tasks are blocked, notify the team lead or help resolve blocking tasks
+
+**IMPORTANT notes for communication with your team**:
+- Do not use terminal tools to view your team's activity; always send a message to your teammates (and remember, refer to them by name).
+- Your team cannot hear you if you do not use the SendMessage tool. Always send a message to your teammates if you are responding to them.
+- Do NOT send structured JSON status messages like \`{"type":"idle",...}\` or \`{"type":"task_completed",...}\`. Just communicate in plain text when you need to message teammates.
+- Use TaskUpdate to mark tasks completed.
+- If you are an agent in the team, the system will automatically send idle notifications to the team lead when you stop.
+
 `.trim();
 }

package/dist/src/tools/TeamDeleteTool/prompt.js

@@ -1,16 +1,16 @@
 export function getPrompt() {
-    return `
-# TeamDelete
-
-Remove team and task directories when the swarm work is complete.
-
-This operation:
-- Removes the team directory (\`~/.claude/teams/{team-name}/\`)
-- Removes the task directory (\`~/.claude/tasks/{team-name}/\`)
-- Clears team context from the current session
-
-**IMPORTANT**: TeamDelete will fail if the team still has active members. Gracefully terminate teammates first, then call TeamDelete after all teammates have shut down.
-
-Use this when all teammates have finished their work and you want to clean up the team resources. The team name is automatically determined from the current session's team context.
+    return `
+# TeamDelete
+
+Remove team and task directories when the swarm work is complete.
+
+This operation:
+- Removes the team directory (\`~/.claude/teams/{team-name}/\`)
+- Removes the task directory (\`~/.claude/tasks/{team-name}/\`)
+- Clears team context from the current session
+
+**IMPORTANT**: TeamDelete will fail if the team still has active members. Gracefully terminate teammates first, then call TeamDelete after all teammates have shut down.
+
+Use this when all teammates have finished their work and you want to clean up the team resources. The team name is automatically determined from the current session's team context.
 `.trim();
 }

package/dist/src/utils/advisor.js

@@ -59,19 +59,19 @@ export function getAdvisorUsage(usage) {
     }
     return iterations.filter(it => it.type === 'advisor_message');
 }
-export const ADVISOR_TOOL_INSTRUCTIONS = `# Advisor Tool
-
-You have access to an \`advisor\` tool backed by a stronger reviewer model. It takes NO parameters -- when you call it, your entire conversation history is automatically forwarded. The advisor sees the task, every tool call you've made, every result you've seen.
-
-Call advisor BEFORE substantive work -- before writing code, before committing to an interpretation, before building on an assumption. If the task requires orientation first (finding files, reading code, seeing what's there), do that, then call advisor. Orientation is not substantive work. Writing, editing, and declaring an answer are.
-
-Also call advisor:
-- When you believe the task is complete. BEFORE this call, make your deliverable durable: write the file, stage the change, save the result. The advisor call takes time; if the session ends during it, a durable result persists and an unwritten one doesn't.
-- When stuck -- errors recurring, approach not converging, results that don't fit.
-- When considering a change of approach.
-
-On tasks longer than a few steps, call advisor at least once before committing to an approach and once before declaring done. On short reactive tasks where the next action is dictated by tool output you just read, you don't need to keep calling -- the advisor adds most of its value on the first call, before the approach crystallizes.
-
-Give the advice serious weight. If you follow a step and it fails empirically, or you have primary-source evidence that contradicts a specific claim (the file says X, the code does Y), adapt. A passing self-test is not evidence the advice is wrong -- it's evidence your test doesn't check what the advice is checking.
-
+export const ADVISOR_TOOL_INSTRUCTIONS = `# Advisor Tool
+
+You have access to an \`advisor\` tool backed by a stronger reviewer model. It takes NO parameters -- when you call it, your entire conversation history is automatically forwarded. The advisor sees the task, every tool call you've made, every result you've seen.
+
+Call advisor BEFORE substantive work -- before writing code, before committing to an interpretation, before building on an assumption. If the task requires orientation first (finding files, reading code, seeing what's there), do that, then call advisor. Orientation is not substantive work. Writing, editing, and declaring an answer are.
+
+Also call advisor:
+- When you believe the task is complete. BEFORE this call, make your deliverable durable: write the file, stage the change, save the result. The advisor call takes time; if the session ends during it, a durable result persists and an unwritten one doesn't.
+- When stuck -- errors recurring, approach not converging, results that don't fit.
+- When considering a change of approach.
+
+On tasks longer than a few steps, call advisor at least once before committing to an approach and once before declaring done. On short reactive tasks where the next action is dictated by tool output you just read, you don't need to keep calling -- the advisor adds most of its value on the first call, before the approach crystallizes.
+
+Give the advice serious weight. If you follow a step and it fails empirically, or you have primary-source evidence that contradicts a specific claim (the file says X, the code does Y), adapt. A passing self-test is not evidence the advice is wrong -- it's evidence your test doesn't check what the advice is checking.
+
 If you've already retrieved data pointing one way and the advisor points another: don't silently switch. Surface the conflict in one more advisor call -- "I found X, you suggest Y, which constraint breaks the tie?" The advisor saw your evidence but may have underweighted it; a reconcile call is cheaper than committing to the wrong branch.`;

package/dist/src/utils/api.js

@@ -348,8 +348,8 @@ export function prependUserContext(messages, context) {
         createUserMessage({
             content: `<system-reminder>\nAs you answer the user's questions, you can use the following context:\n${Object.entries(context)
                 .map(([key, value]) => `# ${key}\n${value}`)
-                .join('\n')}
-
+                .join('\n')}
+
       IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task.\n</system-reminder>\n`,
             isMeta: true,
         }),

package/dist/src/utils/autoUpdater.js

@@ -50,14 +50,14 @@ export async function assertMinVersion() {
         if (versionConfig.minVersion &&
             lt(MACRO.VERSION, versionConfig.minVersion)) {
             // biome-ignore lint/suspicious/noConsole:: intentional console output
-            console.error(`
-It looks like your version of Context Code (${MACRO.VERSION}) needs an update.
-A newer version (${versionConfig.minVersion} or higher) is required to continue.
-
-To update, please run:
-    claude update
-
-This will ensure you have access to the latest features and improvements.
+            console.error(`
+It looks like your version of Context Code (${MACRO.VERSION}) needs an update.
+A newer version (${versionConfig.minVersion} or higher) is required to continue.
+
+To update, please run:
+    claude update
+
+This will ensure you have access to the latest features and improvements.
 `);
             gracefulShutdownSync(1);
         }
@@ -391,16 +391,16 @@ export async function installGlobalPackage(specificVersion) {
                 currentVersion: MACRO.VERSION,
             });
             // biome-ignore lint/suspicious/noConsole:: intentional console output
-            console.error(`
-Error: Windows NPM detected in WSL
-
-You're running Context Code in WSL but using the Windows NPM installation from /mnt/c/.
-This configuration is not supported for updates.
-
-To fix this issue:
-  1. Install Node.js within your Linux distribution: e.g. sudo apt install nodejs npm
-  2. Make sure Linux NPM is in your PATH before the Windows version
-  3. Try updating again with 'context update'
+            console.error(`
+Error: Windows NPM detected in WSL
+
+You're running Context Code in WSL but using the Windows NPM installation from /mnt/c/.
+This configuration is not supported for updates.
+
+To fix this issue:
+  1. Install Node.js within your Linux distribution: e.g. sudo apt install nodejs npm
+  2. Make sure Linux NPM is in your PATH before the Windows version
+  3. Try updating again with 'context update'
 `);
             return 'install_failed';
         }

package/dist/src/utils/bash/ShellSnapshot.js

@@ -170,62 +170,62 @@ function getUserSnapshotContent(configFile) {
     let content = '';
     // User functions
     if (isZsh) {
-        content += `
-      echo "# Functions" >> "$SNAPSHOT_FILE"
-
-      # Force autoload all functions first
-      typeset -f > /dev/null 2>&1
-
-      # Now get user function names - filter completion functions (single underscore prefix)
-      # but keep double-underscore helpers (e.g. __zsh_like_cd from mise, __pyenv_init)
-      typeset +f | grep -vE '^_[^_]' | while read func; do
-        typeset -f "$func" >> "$SNAPSHOT_FILE"
-      done
+        content += `
+      echo "# Functions" >> "$SNAPSHOT_FILE"
+
+      # Force autoload all functions first
+      typeset -f > /dev/null 2>&1
+
+      # Now get user function names - filter completion functions (single underscore prefix)
+      # but keep double-underscore helpers (e.g. __zsh_like_cd from mise, __pyenv_init)
+      typeset +f | grep -vE '^_[^_]' | while read func; do
+        typeset -f "$func" >> "$SNAPSHOT_FILE"
+      done
     `;
     }
     else {
-        content += `
-      echo "# Functions" >> "$SNAPSHOT_FILE"
-
-      # Force autoload all functions first
-      declare -f > /dev/null 2>&1
-
-      # Now get user function names - filter completion functions (single underscore prefix)
-      # but keep double-underscore helpers (e.g. __zsh_like_cd from mise, __pyenv_init)
-      declare -F | cut -d' ' -f3 | grep -vE '^_[^_]' | while read func; do
-        # Encode the function to base64, preserving all special characters
-        encoded_func=$(declare -f "$func" | base64 )
-        # Write the function definition to the snapshot
-        echo "eval ${LITERAL_BACKSLASH}"${LITERAL_BACKSLASH}$(echo '$encoded_func' | base64 -d)${LITERAL_BACKSLASH}" > /dev/null 2>&1" >> "$SNAPSHOT_FILE"
-      done
+        content += `
+      echo "# Functions" >> "$SNAPSHOT_FILE"
+
+      # Force autoload all functions first
+      declare -f > /dev/null 2>&1
+
+      # Now get user function names - filter completion functions (single underscore prefix)
+      # but keep double-underscore helpers (e.g. __zsh_like_cd from mise, __pyenv_init)
+      declare -F | cut -d' ' -f3 | grep -vE '^_[^_]' | while read func; do
+        # Encode the function to base64, preserving all special characters
+        encoded_func=$(declare -f "$func" | base64 )
+        # Write the function definition to the snapshot
+        echo "eval ${LITERAL_BACKSLASH}"${LITERAL_BACKSLASH}$(echo '$encoded_func' | base64 -d)${LITERAL_BACKSLASH}" > /dev/null 2>&1" >> "$SNAPSHOT_FILE"
+      done
     `;
     }
     // Shell options
     if (isZsh) {
-        content += `
-      echo "# Shell Options" >> "$SNAPSHOT_FILE"
-      setopt | sed 's/^/setopt /' | head -n 1000 >> "$SNAPSHOT_FILE"
+        content += `
+      echo "# Shell Options" >> "$SNAPSHOT_FILE"
+      setopt | sed 's/^/setopt /' | head -n 1000 >> "$SNAPSHOT_FILE"
     `;
     }
     else {
-        content += `
-      echo "# Shell Options" >> "$SNAPSHOT_FILE"
-      shopt -p | head -n 1000 >> "$SNAPSHOT_FILE"
-      set -o | grep "on" | awk '{print "set -o " $1}' | head -n 1000 >> "$SNAPSHOT_FILE"
-      echo "shopt -s expand_aliases" >> "$SNAPSHOT_FILE"
+        content += `
+      echo "# Shell Options" >> "$SNAPSHOT_FILE"
+      shopt -p | head -n 1000 >> "$SNAPSHOT_FILE"
+      set -o | grep "on" | awk '{print "set -o " $1}' | head -n 1000 >> "$SNAPSHOT_FILE"
+      echo "shopt -s expand_aliases" >> "$SNAPSHOT_FILE"
     `;
     }
     // User aliases
-    content += `
-      echo "# Aliases" >> "$SNAPSHOT_FILE"
-      # Filter out winpty aliases on Windows to avoid "stdin is not a tty" errors
-      # Git Bash automatically creates aliases like "alias node='winpty node.exe'" for
-      # programs that need Win32 Console in mintty, but winpty fails when there's no TTY
-      if [[ "$OSTYPE" == "msys" ]] || [[ "$OSTYPE" == "cygwin" ]]; then
-        alias | grep -v "='winpty " | sed 's/^alias //g' | sed 's/^/alias -- /' | head -n 1000 >> "$SNAPSHOT_FILE"
-      else
-        alias | sed 's/^alias //g' | sed 's/^/alias -- /' | head -n 1000 >> "$SNAPSHOT_FILE"
-      fi
+    content += `
+      echo "# Aliases" >> "$SNAPSHOT_FILE"
+      # Filter out winpty aliases on Windows to avoid "stdin is not a tty" errors
+      # Git Bash automatically creates aliases like "alias node='winpty node.exe'" for
+      # programs that need Win32 Console in mintty, but winpty fails when there's no TTY
+      if [[ "$OSTYPE" == "msys" ]] || [[ "$OSTYPE" == "cygwin" ]]; then
+        alias | grep -v "='winpty " | sed 's/^alias //g' | sed 's/^/alias -- /' | head -n 1000 >> "$SNAPSHOT_FILE"
+      else
+        alias | sed 's/^alias //g' | sed 's/^/alias -- /' | head -n 1000 >> "$SNAPSHOT_FILE"
+      fi
   `;
     return content;
 }
@@ -253,28 +253,28 @@ async function getClaudeCodeSnapshotContent() {
     // We use a subshell to unalias rg before checking, so that user aliases like
     // `alias rg='rg --smart-case'` don't shadow the real binary check. The subshell
     // ensures we don't modify the user's aliases in the parent shell.
-    content += `
-      # Check for rg availability
-      echo "# Check for rg availability" >> "$SNAPSHOT_FILE"
-      echo "if ! (unalias rg 2>/dev/null; command -v rg) >/dev/null 2>&1; then" >> "$SNAPSHOT_FILE"
+    content += `
+      # Check for rg availability
+      echo "# Check for rg availability" >> "$SNAPSHOT_FILE"
+      echo "if ! (unalias rg 2>/dev/null; command -v rg) >/dev/null 2>&1; then" >> "$SNAPSHOT_FILE"
   `;
     if (rgIntegration.type === 'function') {
         // For embedded ripgrep, write the function definition using heredoc
-        content += `
-      cat >> "$SNAPSHOT_FILE" << 'RIPGREP_FUNC_END'
-  ${rgIntegration.snippet}
-RIPGREP_FUNC_END
+        content += `
+      cat >> "$SNAPSHOT_FILE" << 'RIPGREP_FUNC_END'
+  ${rgIntegration.snippet}
+RIPGREP_FUNC_END
     `;
     }
     else {
         // For regular ripgrep, write a simple alias
         const escapedSnippet = rgIntegration.snippet.replace(/'/g, "'\\''");
-        content += `
-      echo '  alias rg='"'${escapedSnippet}'" >> "$SNAPSHOT_FILE"
+        content += `
+      echo '  alias rg='"'${escapedSnippet}'" >> "$SNAPSHOT_FILE"
     `;
     }
-    content += `
-      echo "fi" >> "$SNAPSHOT_FILE"
+    content += `
+      echo "fi" >> "$SNAPSHOT_FILE"
   `;
     // For ant-native builds, shadow find/grep with bfs/ugrep embedded in the bun
     // binary. Unlike rg (which only activates if system rg is absent), we always
@@ -282,19 +282,19 @@ RIPGREP_FUNC_END
     // consistent fast behavior in Claude's shell.
     const findGrepIntegration = createFindGrepShellIntegration();
     if (findGrepIntegration !== null) {
-        content += `
-      # Shadow find/grep with embedded bfs/ugrep (ant-native only)
-      echo "# Shadow find/grep with embedded bfs/ugrep" >> "$SNAPSHOT_FILE"
-      cat >> "$SNAPSHOT_FILE" << 'FIND_GREP_FUNC_END'
-${findGrepIntegration}
-FIND_GREP_FUNC_END
+        content += `
+      # Shadow find/grep with embedded bfs/ugrep (ant-native only)
+      echo "# Shadow find/grep with embedded bfs/ugrep" >> "$SNAPSHOT_FILE"
+      cat >> "$SNAPSHOT_FILE" << 'FIND_GREP_FUNC_END'
+${findGrepIntegration}
+FIND_GREP_FUNC_END
     `;
     }
     // Add PATH to the file
-    content += `
-
-      # Add PATH to the file
-      echo "export PATH=${quote([pathValue || ''])}" >> "$SNAPSHOT_FILE"
+    content += `
+
+      # Add PATH to the file
+      echo "export PATH=${quote([pathValue || ''])}" >> "$SNAPSHOT_FILE"
   `;
     return content;
 }
@@ -312,27 +312,27 @@ async function getSnapshotScript(shellPath, snapshotFilePath, configFileExists)
                 'echo "shopt -s expand_aliases" >> "$SNAPSHOT_FILE"'
             : '';
     const claudeCodeContent = await getClaudeCodeSnapshotContent();
-    const script = `SNAPSHOT_FILE=${quote([snapshotFilePath])}
-      ${configFileExists ? `source "${configFile}" < /dev/null` : '# No user config file to source'}
-
-      # First, create/clear the snapshot file
-      echo "# Snapshot file" >| "$SNAPSHOT_FILE"
-
-      # When this file is sourced, we first unalias to avoid conflicts
-      # This is necessary because aliases get "frozen" inside function definitions at definition time,
-      # which can cause unexpected behavior when functions use commands that conflict with aliases
-      echo "# Unset all aliases to avoid conflicts with functions" >> "$SNAPSHOT_FILE"
-      echo "unalias -a 2>/dev/null || true" >> "$SNAPSHOT_FILE"
-
-      ${userContent}
-
-      ${claudeCodeContent}
-
-      # Exit silently on success, only report errors
-      if [ ! -f "$SNAPSHOT_FILE" ]; then
-        echo "Error: Snapshot file was not created at $SNAPSHOT_FILE" >&2
-        exit 1
-      fi
+    const script = `SNAPSHOT_FILE=${quote([snapshotFilePath])}
+      ${configFileExists ? `source "${configFile}" < /dev/null` : '# No user config file to source'}
+
+      # First, create/clear the snapshot file
+      echo "# Snapshot file" >| "$SNAPSHOT_FILE"
+
+      # When this file is sourced, we first unalias to avoid conflicts
+      # This is necessary because aliases get "frozen" inside function definitions at definition time,
+      # which can cause unexpected behavior when functions use commands that conflict with aliases
+      echo "# Unset all aliases to avoid conflicts with functions" >> "$SNAPSHOT_FILE"
+      echo "unalias -a 2>/dev/null || true" >> "$SNAPSHOT_FILE"
+
+      ${userContent}
+
+      ${claudeCodeContent}
+
+      # Exit silently on success, only report errors
+      if [ ! -f "$SNAPSHOT_FILE" ]; then
+        echo "Error: Snapshot file was not created at $SNAPSHOT_FILE" >&2
+        exit 1
+      fi
     `;
     return script;
 }