src/tui/components/Header.tsx (1)

130-148: Consider using resolvedSandboxMode when mode is 'auto'.

The HeaderProps interface includes a resolvedSandboxMode prop (as seen in src/tui/types.ts:103-104) to show what 'auto' resolved to, but this function doesn't accept or use it. When sandbox mode is 'auto', displaying "auto" may be less informative than showing the actual resolved backend (e.g., "bwrap" or "sandbox-exec").

♻️ Suggested improvement

 function getSandboxDisplay(
-  sandboxConfig: HeaderProps['sandboxConfig']
+  sandboxConfig: HeaderProps['sandboxConfig'],
+  resolvedSandboxMode?: Exclude<import('../types.js').SandboxMode, 'auto'>
 ): string | null {
   if (!sandboxConfig?.enabled) {
     return null;
   }

   const mode = sandboxConfig.mode ?? 'auto';
   if (mode === 'off') {
     return null;
   }

+  // Show resolved mode when 'auto', otherwise show configured mode
+  const displayMode = mode === 'auto' && resolvedSandboxMode ? resolvedSandboxMode : mode;
   const networkSuffix = sandboxConfig.network === false ? ' (no-net)' : '';
-  return `${mode}${networkSuffix}`;
+  return `${displayMode}${networkSuffix}`;
 }

Then update the call site:

-  const sandboxDisplay = getSandboxDisplay(sandboxConfig);
+  const sandboxDisplay = getSandboxDisplay(sandboxConfig, resolvedSandboxMode);

And add resolvedSandboxMode to the destructured props.

src/plugins/agents/types.ts (3)

104-105: Add JSDoc comment for the sandbox property.

Other properties in AgentExecuteOptions have descriptive comments. Adding documentation here would maintain consistency and clarify the property's purpose.

📝 Suggested documentation

+  /** Sandbox configuration for isolated execution */
   sandbox?: SandboxConfig;

---

210-215: Add JSDoc documentation for AgentSandboxRequirements.

The interface lacks documentation explaining its purpose and the semantics of each property. This would help implementers understand what paths should go where (e.g., authPaths are mounted read-write for token refresh, binaryPaths and runtimePaths are read-only).

📝 Suggested documentation

+/**
+ * Sandbox requirements declared by an agent plugin.
+ * These paths are mounted into the sandbox to allow the agent to function.
+ */
 export interface AgentSandboxRequirements {
+  /** Paths requiring read-write access (e.g., for OAuth token refresh) */
   authPaths: string[];
+  /** Paths containing binaries the agent needs (mounted read-only) */
   binaryPaths: string[];
+  /** Additional runtime paths the agent needs (mounted read-only) */
   runtimePaths: string[];
+  /** Whether the agent requires network access for API calls */
   requiresNetwork: boolean;
 }

---

300-301: Add JSDoc documentation for getSandboxRequirements.

Other methods in the AgentPlugin interface have descriptive JSDoc comments. Adding documentation here would maintain consistency.

📝 Suggested documentation

+  /**
+   * Get sandbox requirements for this agent.
+   * Declares paths and capabilities needed when running in a sandboxed environment.
+   * `@returns` Sandbox requirements including auth paths, binary paths, and network needs
+   */
   getSandboxRequirements(): AgentSandboxRequirements;

src/tui/components/ProgressDashboard.tsx (1)

61-64: Consider extracting shared sandbox display logic.

The mode display logic (auto (${resolvedSandboxMode})) is duplicated in IterationDetailView.tsx (lines 703-706). Consider extracting a shared helper function to ensure consistent formatting across components.

src/tui/components/IterationDetailView.tsx (1)

715-728: Consider improving path list display for readability.

When allowPaths or readOnlyPaths contain many entries, the comma-separated display could become unwieldy. Consider displaying each path on a separate line or truncating with a count indicator (e.g., "3 paths configured") with expansion on demand.

src/config/index.ts (1)

166-168: Shallow merge may not handle array properties as expected.

The spread operator performs a shallow merge. If both merged.sandbox and project.sandbox contain allowPaths or readOnlyPaths arrays, the project's arrays will completely replace the global ones rather than merging them. This is consistent with how other arrays are handled in this function (see lines 152-154), but worth noting that users cannot extend global path lists at the project level—they must re-specify all paths.

If this is the intended behaviour, consider adding a comment to clarify, similar to line 152's comment about arrays being replaced.

src/config/types.ts (1)

253-254: Consider making sandbox required on RalphConfig.

Since buildConfig in src/config/index.ts always constructs a sandbox object (lines 531-535), the property will never be undefined at runtime. Making it sandbox: SandboxConfig (required) would provide better type safety for consumers and eliminate unnecessary optional chaining in downstream code.

However, this is a minor refinement and the current optional approach is safe.

🔧 Suggested change

-  sandbox?: SandboxConfig;
+  sandbox: SandboxConfig;

src/plugins/agents/base.ts (2)

400-412: Minor: resolveSandboxConfig always returns undefined when sandbox is disabled.

The function returns undefined when sandboxConfig?.enabled is falsy, but this includes the case where sandboxConfig exists with enabled: false. This is correct behaviour, but the naming could be clearer. Consider adding a brief comment to clarify that returning undefined means "no sandboxing".

---

380-393: Timeout cleanup relies on completeExecution being called.

The timeout handler checks this.executions.has(executionId) before killing, which works because completeExecution removes the execution from the map. However, if the process completes normally before the timeout fires, the execution.timeoutId is cleared in completeExecution (line 486-488). This is correct.

The nested setTimeout for the SIGKILL follow-up (lines 386-390) could potentially fire after the execution is already completed if there's a race. The check on line 387 guards against this, but consider storing this inner timeout ID as well for explicit cleanup.

🔧 Suggested improvement for explicit cleanup

+      let killTimeoutId: ReturnType<typeof setTimeout> | undefined;
       if (timeout > 0) {
         execution.timeoutId = setTimeout(() => {
           if (this.executions.has(executionId)) {
             proc.kill('SIGTERM');
             // Give it 5 seconds to terminate gracefully
-            setTimeout(() => {
+            killTimeoutId = setTimeout(() => {
               if (this.executions.has(executionId)) {
                 proc.kill('SIGKILL');
               }
             }, 5000);
           }
         }, timeout);
       }

Then in completeExecution, clear both timeouts.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

src/plugins/agents/droid/outputParser.ts (1)

528-571: Surface tool-result failures instead of dropping them.

The code at lines 556-559 pushes a plain tool_result event regardless of whether the tool execution failed. Since processAgentEvents intentionally skips tool_result events (per the relevant code snippet from output-formatting.ts lines 339-342), any failures marked via isError or status will be invisible to the user.

Consider mapping error results to error events:

🩹 Proposed fix

   // Parse tool results (shared logic will skip these)
   if (message.toolResults && message.toolResults.length > 0) {
-    events.push({ type: 'tool_result' });
+    for (const result of message.toolResults) {
+      if (result.isError || (result.status && result.status.toLowerCase() === 'error')) {
+        const statusSuffix = result.status ? ` (status: ${result.status})` : '';
+        events.push({ type: 'error', message: `Tool execution failed${statusSuffix}` });
+      } else {
+        events.push({ type: 'tool_result' });
+      }
+    }
   }

examples/validation.ts (1)

42-47: Avoid duplicate Number(s) conversion.

Number(s) is called twice on line 46. Consider storing the result in a variable to avoid redundant parsing.

♻️ Proposed refactor

 export function isNumeric(s: string): boolean {
   if (s.trim() === "") {
     return false;
   }
-  return !isNaN(Number(s)) && isFinite(Number(s));
+  const num = Number(s);
+  return !isNaN(num) && isFinite(num);
 }

examples/timers.ts (2)

28-31: Consider using any[] for the generic constraint.

The constraint (...args: unknown[]) => unknown can cause type inference issues with functions that have specific typed parameters due to contravariance. Using any[] is the standard pattern for higher-order function wrappers like debounce/throttle.

♻️ Suggested fix

-export function debounce<T extends (...args: unknown[]) => unknown>(
+export function debounce<T extends (...args: any[]) => any>(
   fn: T,
   ms: number
 ): (...args: Parameters<T>) => void {

---

54-66: Note: Leading-edge throttle drops intermediate calls.

This throttle implementation only executes on the leading edge — calls made during the throttle period are silently dropped with no trailing execution. This may be acceptable for your use case, but be aware that:

• The last call during a burst won't execute if it falls within the throttle window.
• For scroll/resize handlers, this could mean missing the final position.

If trailing execution is needed, consider adding an optional trailing parameter or documenting this behaviour explicitly.

Also, same type constraint suggestion as debounce:

♻️ Suggested fix for type constraint

-export function throttle<T extends (...args: unknown[]) => unknown>(
+export function throttle<T extends (...args: any[]) => any>(
   fn: T,
   ms: number
 ): (...args: Parameters<T>) => void {

examples/slugs.ts (1)

24-36: Filter empty segments to avoid extra spaces on malformed slugs.
This keeps output tidy for inputs with consecutive or leading/trailing hyphens.

♻️ Proposed refinement

 export function unslugify(s: string): string {
   return s
     .split('-')
+    .filter(Boolean)
     .map(word => word.charAt(0).toUpperCase() + word.slice(1))
     .join(' ');
 }

examples/dates.ts (1)

17-30: Consider UTC-normalising to avoid DST/time-of-day drift.
If callers expect calendar day differences (rather than elapsed 24‑hour blocks), the current millisecond diff can be off by one around DST or non‑midnight inputs. Normalising to UTC midnight makes the intent unambiguous.

♻️ Suggested adjustment

 export function daysBetween(date1: Date, date2: Date): number {
   const msPerDay = 24 * 60 * 60 * 1000;
-  const diffMs = Math.abs(date2.getTime() - date1.getTime());
-  return Math.floor(diffMs / msPerDay);
+  const utc1 = Date.UTC(date1.getUTCFullYear(), date1.getUTCMonth(), date1.getUTCDate());
+  const utc2 = Date.UTC(date2.getUTCFullYear(), date2.getUTCMonth(), date2.getUTCDate());
+  return Math.abs(utc2 - utc1) / msPerDay;
 }

examples/objects.ts (1)

19-23: Prefer own-property checks in pick() to avoid inherited keys.
key in obj can include prototype properties for class instances. Using hasOwnProperty aligns with typical pick/omit expectations.

♻️ Proposed change

-  for (const key of keys) {
-    if (key in obj) {
-      result[key] = obj[key];
-    }
-  }
+  for (const key of keys) {
+    if (Object.prototype.hasOwnProperty.call(obj, key)) {
+      result[key] = obj[key];
+    }
+  }

src/tui/components/RightPanel.tsx (1)

528-546: Iteration segments are plumbed but currently unused.
If this is intentionally deferred, consider a short TODO/feature flag so it doesn’t linger unnoticed.

Also applies to: 576-579

src/tui/output-parser.ts (1)

225-313: Avoid recomputing segment length on every push.
The reduce over the full segment list each chunk can get expensive on long streams; tracking a running length is cheaper.

♻️ Possible optimisation

 export class StreamingOutputParser {
   private buffer = '';
   private parsedOutput = '';
   private parsedSegments: FormattedSegment[] = [];
+  private parsedSegmentsLength = 0;
   private lastResultText = '';
   private lastCostSummary = '';
@@
     if (newSegments.length > 0) {
       this.parsedSegments.push(...newSegments);
+      this.parsedSegmentsLength += newSegments.reduce((acc, s) => acc + s.text.length, 0);
 
-      const totalLength = this.parsedSegments.reduce((acc, s) => acc + s.text.length, 0);
-      if (totalLength > MAX_PARSED_OUTPUT_SIZE) {
+      if (this.parsedSegmentsLength > MAX_PARSED_OUTPUT_SIZE) {
         // Simple trim: keep last N segments that fit within limit
         let kept = 0;
         let keptLength = 0;
@@
         this.parsedSegments = [
           { text: '[...output trimmed...]\n', color: 'muted' },
           ...this.parsedSegments.slice(-kept),
         ];
+        this.parsedSegmentsLength = this.parsedSegments.reduce((acc, s) => acc + s.text.length, 0);
       }
     }
@@
   reset(): void {
     this.buffer = '';
     this.parsedOutput = '';
     this.parsedSegments = [];
+    this.parsedSegmentsLength = 0;
     this.lastResultText = '';
     this.lastCostSummary = '';

Also applies to: 537-537

src/plugins/agents/output-formatting.ts (2)

65-89: Consider edge case: commands with multiple semicolons.

The formatCommand function takes only the last part after splitting on ;. If the actual command contains semicolons (e.g., in a shell one-liner), this could truncate meaningful content.

This is a minor edge case — the current behaviour is reasonable for the common pattern of stripping ENV_VAR=val; actual_command.

---

183-185: Truncation may lose important context for edit operations.

When old_string or new_string exceed 50 characters, the diff display truncates both to 50 chars plus .... Consider showing the full strings when they're reasonably short, or providing a way to view the full diff:

-  if (input.old_string && input.new_string) {
-    parts.push(`edit: "${input.old_string.slice(0, 50)}..." → "${input.new_string.slice(0, 50)}..."`);
+  if (input.old_string && input.new_string) {
+    const oldPreview = input.old_string.length > 50 ? input.old_string.slice(0, 50) + '...' : input.old_string;
+    const newPreview = input.new_string.length > 50 ? input.new_string.slice(0, 50) + '...' : input.new_string;
+    parts.push(`edit: "${oldPreview}" → "${newPreview}"`);
   }

src/plugins/agents/builtin/claude.ts (1)

414-455: The onStdoutSegments wrapper appears to be a no-op.

Lines 425-429 set onStdoutSegments to an empty function that does nothing when isStreamingJson is true. The actual segment emission happens inside the onStdout wrapper (lines 436-440). While this works, the empty callback assignment is confusing.

Consider removing the no-op assignment for clarity:

♻️ Proposed refactor

     const parsedOptions: AgentExecuteOptions = {
       ...options,
-      // TUI-native segments callback (preferred)
-      onStdoutSegments: options?.onStdoutSegments && isStreamingJson
-        ? (/* original segments ignored - we parse from raw */) => {
-            // This callback is set up but actual segments come from wrapping onStdout below
-          }
-        : options?.onStdoutSegments,
+      // Don't pass through onStdoutSegments when streaming JSON - we emit segments from onStdout
+      onStdoutSegments: isStreamingJson ? undefined : options?.onStdoutSegments,
       // Legacy string callback or wrapper that calls both callbacks
       onStdout: isStreamingJson && (options?.onStdout || options?.onStdoutSegments)

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

src/tui/output-parser.ts (1)

417-478: ANSI codes not stripped from plain-text segments.

Plain-text segments returned at lines 437, 453, 460, and 474 can still carry ANSI sequences, which may cause TUI rendering artefacts. This was flagged in a previous review but remains unaddressed in these code paths.

🐛 Suggested fix

     // Not JSON - return as plain text segment if it's not just whitespace
     if (!trimmed.startsWith('{')) {
-      return [{ text: trimmed }];
+      return [{ text: stripAnsiCodes(trimmed) }];
     }
@@
       // Assistant message with content - show the text as plain segment
       if (event.type === 'assistant') {
         const assistantEvent = event as AssistantEvent;
         const content = assistantEvent.message?.content;
         if (typeof content === 'string' && content.trim()) {
-          return [{ text: content }];
+          return [{ text: stripAnsiCodes(content) }];
         }
         if (Array.isArray(content)) {
           const textParts = content
             .filter((c): c is { type: string; text: string } => c.type === 'text' && !!c.text)
             .map((c) => c.text);
           if (textParts.length > 0) {
-            return [{ text: textParts.join('') }];
+            return [{ text: stripAnsiCodes(textParts.join('')) }];
           }
         }
       }
@@
     } catch {
       // Not valid JSON - return as plain text if meaningful
       if (trimmed.length > 0 && !trimmed.startsWith('{')) {
-        return [{ text: trimmed }];
+        return [{ text: stripAnsiCodes(trimmed) }];
       }
       return [];
     }

src/plugins/agents/output-formatting.ts (1)

65-89: Code duplication between formatCommand and cleanCommand.

Both functions share nearly identical logic for normalising commands: newline replacement, semicolon splitting, env-var stripping, and truncation. The only difference is formatCommand prepends $ .

Consider extracting the shared logic to avoid drift:

♻️ Suggested refactor

+/**
+ * Clean a command string (remove env vars, normalize whitespace, truncate).
+ */
+function cleanCommand(command: string): string {
+  let cmd = command.replace(/\n/g, ' ').trim();
+
+  if (cmd.includes(';')) {
+    const parts = cmd.split(';');
+    cmd = parts[parts.length - 1].trim();
+  }
+
+  const envVarPattern = /^(\s*\w+=[^\s]*\s+)+/;
+  if (envVarPattern.test(cmd)) {
+    cmd = cmd.replace(envVarPattern, '').trim();
+  }
+
+  if (cmd.length > 100) {
+    cmd = cmd.slice(0, 100) + '...';
+  }
+
+  return cmd;
+}
+
 export function formatCommand(command: string): string {
-  // Normalize newlines to spaces
-  let cmd = command.replace(/\n/g, ' ').trim();
-
-  // Extract actual command from env var setup
-  // Pattern: ENV_VAR=value ... ; actual_command
-  if (cmd.includes(';')) {
-    const parts = cmd.split(';');
-    cmd = parts[parts.length - 1].trim();
-  }
-
-  // Also handle inline env vars before command (VAR=val VAR2=val2 command)
-  // If the command starts with lots of VAR= patterns, try to find the actual command
-  const envVarPattern = /^(\s*\w+=[^\s]*\s+)+/;
-  if (envVarPattern.test(cmd)) {
-    cmd = cmd.replace(envVarPattern, '').trim();
-  }
-
-  // Truncate very long commands
-  if (cmd.length > 100) {
-    cmd = cmd.slice(0, 100) + '...';
-  }
-
-  return `$ ${cmd}`;
+  return `$ ${cleanCommand(command)}`;
 }

Also applies to: 197-215

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

src/plugins/agents/output-formatting.ts (1)

183-185: Only append ellipsis when truncating edit previews.

Right now "..." is added even for short strings, which is misleading.

🐛 Suggested fix

-  if (input.old_string && input.new_string) {
-    parts.push(`edit: "${input.old_string.slice(0, 50)}..." → "${input.new_string.slice(0, 50)}..."`);
-  }
+  if (input.old_string && input.new_string) {
+    const oldPreview = input.old_string.length > 50
+      ? `${input.old_string.slice(0, 50)}...`
+      : input.old_string;
+    const newPreview = input.new_string.length > 50
+      ? `${input.new_string.slice(0, 50)}...`
+      : input.new_string;
+    parts.push(`edit: "${oldPreview}" → "${newPreview}"`);
+  }
@@
-  if (input.old_string && input.new_string) {
+  if (input.old_string && input.new_string) {
+    const oldPreview = input.old_string.length > 50
+      ? input.old_string.slice(0, 50) + '...'
+      : input.old_string;
+    const newPreview = input.new_string.length > 50
+      ? input.new_string.slice(0, 50) + '...'
+      : input.new_string;
     segments.push({ text: ' edit: "', color: 'muted' });
-    segments.push({ text: input.old_string.slice(0, 50) + '...', color: 'pink' });
+    segments.push({ text: oldPreview, color: 'pink' });
     segments.push({ text: '" → "', color: 'muted' });
-    segments.push({ text: input.new_string.slice(0, 50) + '...', color: 'green' });
+    segments.push({ text: newPreview, color: 'green' });
     segments.push({ text: '"', color: 'muted' });
   }

Also applies to: 280-285

src/plugins/agents/output-formatting.ts (1)

65-88: Deduplicate command normalisation to avoid drift.

formatCommand and cleanCommand repeat identical logic, which risks divergence and inconsistent truncation. Consider extracting a shared helper.

♻️ Proposed refactor

+function normalizeCommand(command: string): string {
+  let cmd = command.replace(/\n/g, ' ').trim();
+  if (cmd.includes(';')) {
+    const parts = cmd.split(';');
+    cmd = parts[parts.length - 1].trim();
+  }
+  const envVarPattern = /^(\s*\w+=[^\s]*\s+)+/;
+  if (envVarPattern.test(cmd)) {
+    cmd = cmd.replace(envVarPattern, '').trim();
+  }
+  if (cmd.length > 100) {
+    cmd = cmd.slice(0, 100) + '...';
+  }
+  return cmd;
+}
+
 export function formatCommand(command: string): string {
-  // Normalize newlines to spaces
-  let cmd = command.replace(/\n/g, ' ').trim();
-
-  // Extract actual command from env var setup
-  // Pattern: ENV_VAR=value ... ; actual_command
-  if (cmd.includes(';')) {
-    const parts = cmd.split(';');
-    cmd = parts[parts.length - 1].trim();
-  }
-
-  // Also handle inline env vars before command (VAR=val VAR2=val2 command)
-  // If the command starts with lots of VAR= patterns, try to find the actual command
-  const envVarPattern = /^(\s*\w+=[^\s]*\s+)+/;
-  if (envVarPattern.test(cmd)) {
-    cmd = cmd.replace(envVarPattern, '').trim();
-  }
-
-  // Truncate very long commands
-  if (cmd.length > 100) {
-    cmd = cmd.slice(0, 100) + '...';
-  }
-
-  return `$ ${cmd}`;
+  return `$ ${normalizeCommand(command)}`;
 }
@@
 function cleanCommand(command: string): string {
-  let cmd = command.replace(/\n/g, ' ').trim();
-
-  if (cmd.includes(';')) {
-    const parts = cmd.split(';');
-    cmd = parts[parts.length - 1].trim();
-  }
-
-  const envVarPattern = /^(\s*\w+=[^\s]*\s+)+/;
-  if (envVarPattern.test(cmd)) {
-    cmd = cmd.replace(envVarPattern, '').trim();
-  }
-
-  if (cmd.length > 100) {
-    cmd = cmd.slice(0, 100) + '...';
-  }
-
-  return cmd;
+  return normalizeCommand(command);
 }

Also applies to: 194-215

src/plugins/agents/output-formatting.ts (3)

183-185: Avoid misleading ellipsis when edit strings are not truncated.

The edit preview always appends “…”, even when the original strings are ≤ 50 chars.

♻️ Suggested fix

-  if (input.old_string && input.new_string) {
-    parts.push(`edit: "${input.old_string.slice(0, 50)}..." → "${input.new_string.slice(0, 50)}..."`);
-  }
+  if (input.old_string && input.new_string) {
+    const oldPreview =
+      input.old_string.length > 50 ? input.old_string.slice(0, 50) + '...' : input.old_string;
+    const newPreview =
+      input.new_string.length > 50 ? input.new_string.slice(0, 50) + '...' : input.new_string;
+    parts.push(`edit: "${oldPreview}" → "${newPreview}"`);
+  }

---

280-285: Keep segment-based edit previews consistent with actual truncation.

Same unconditional ellipsis issue exists in the segment renderer.

♻️ Suggested fix

-  if (input.old_string && input.new_string) {
-    segments.push({ text: ' edit: "', color: 'muted' });
-    segments.push({ text: input.old_string.slice(0, 50) + '...', color: 'pink' });
-    segments.push({ text: '" → "', color: 'muted' });
-    segments.push({ text: input.new_string.slice(0, 50) + '...', color: 'green' });
-    segments.push({ text: '"', color: 'muted' });
-  }
+  if (input.old_string && input.new_string) {
+    const oldPreview =
+      input.old_string.length > 50 ? input.old_string.slice(0, 50) + '...' : input.old_string;
+    const newPreview =
+      input.new_string.length > 50 ? input.new_string.slice(0, 50) + '...' : input.new_string;
+    segments.push({ text: ' edit: "', color: 'muted' });
+    segments.push({ text: oldPreview, color: 'pink' });
+    segments.push({ text: '" → "', color: 'muted' });
+    segments.push({ text: newPreview, color: 'green' });
+    segments.push({ text: '"', color: 'muted' });
+  }

---

426-429: Replace ANSI regex literal to satisfy Biome control‑character lint.

Biome rejects control characters inside regex literals here.

✅ Lint-safe alternative

-const ANSI_REGEX = /\x1b\[[0-9;?]*[a-zA-Z]|\x1b\][^\x07]*\x07|\x1b[()][AB012]/g;
+const ANSI_REGEX = new RegExp(
+  '\\x1b\\[[0-9;?]*[a-zA-Z]|\\x1b\\][^\\x07]*\\x07|\\x1b[()][AB012]',
+  'g',
+);

src/plugins/agents/output-formatting.test.ts (1)

6-16: Replace require() with an ES import to satisfy lint.

ESLint forbids require() here (pipeline failure).

✅ Suggested fix

 import { describe, expect, test } from 'bun:test';
 import {
   COLORS,
   formatToolName,
   formatPath,
   formatCommand,
   formatError,
   formatPattern,
   formatUrl,
   formatToolCall,
+  processAgentEvents,
 } from './output-formatting.js';

 describe('processAgentEvents', () => {
-  // Import needed for these tests
-  const { processAgentEvents } = require('./output-formatting.js');
-
   test('displays text events with trailing newline', () => {

Also applies to: 269-272