Add support for pseudo-terminal (PTY) mode in CLI commands by thomhurst · Pull Request #309 · Tyrrrz/CliWrap

thomhurst · 2025-12-09T09:21:13Z

Closes #225

I got AI to help me as I'm not the most familiar with native code etc 😄

…ing and validation

Copilot

Pull request overview

This PR adds support for pseudo-terminal (PTY) mode in CLI command execution, enabling applications to behave as if running in an interactive terminal with features like colored output and progress indicators. The implementation is cross-platform, supporting Windows ConPTY (Windows 10 1809+), Linux, and macOS through native PTY APIs.

Key changes:

Platform-specific PTY implementations using Windows ConPTY and Unix openpty
New public API for configuring PTY options (PseudoTerminalOptions, PseudoTerminalOptionsBuilder)
Custom process wrapper (PtyProcessEx) for PTY-based execution with stdin/stdout/stderr redirection
Comprehensive test suite covering configuration, execution, and edge cases

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 95 comments.

Show a summary per file

File	Description
`CliWrap/PseudoTerminalOptions.cs`	Public API for PTY configuration with dimension validation
`CliWrap/Builders/PseudoTerminalOptionsBuilder.cs`	Fluent builder for configuring PTY options
`CliWrap/ICommandConfiguration.cs`	Extends interface to include PTY configuration
`CliWrap/Command.cs`	Adds `WithPseudoTerminal()` methods for enabling PTY mode
`CliWrap/Command.Execution.cs`	Implements PTY-specific execution pipeline with stream piping
`CliWrap/Utils/PseudoTerminal.cs`	Abstract base class for platform-specific PTY implementations
`CliWrap/Utils/WindowsPseudoTerminal.cs`	Windows ConPTY implementation with pipe-based I/O
`CliWrap/Utils/UnixPseudoTerminal.cs`	Unix PTY implementation using openpty()
`CliWrap/Utils/UnixFdStream.cs`	Stream wrapper for Unix file descriptors with read/write operations
`CliWrap/Utils/PtyProcessEx.cs`	PTY process wrapper handling process creation and lifecycle
`CliWrap/Utils/NativeMethods.cs`	P/Invoke declarations for Windows and Unix PTY APIs
`CliWrap.Tests/PseudoTerminalSpecs.cs`	Comprehensive test suite with 1099 lines covering configuration, execution, and edge cases

Comments suppressed due to low confidence (2)

CliWrap/Utils/NativeMethods.cs:106

Minimise the use of unmanaged code.

        public static extern int WaitPid(int pid, out int status, int options);

CliWrap/Utils/NativeMethods.cs:124

Minimise the use of unmanaged code.

        public static extern int CreatePseudoConsole(

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

CliWrap/Utils/WindowsPseudoTerminal.cs

Copilot · 2025-12-09T09:37:05Z

CliWrap/Utils/UnixPseudoTerminal.cs

+    public void CloseSlave()
+    {
+        if (!_slaveFdClosed)
+        {
+            NativeMethods.Unix.Close(_slaveFd);
+            _slaveFdClosed = true;
+        }
+    }


The CloseSlave() method has a check-then-act race condition. If called concurrently from multiple threads, Close() could be called multiple times on the same file descriptor, which could close a different fd if it was reused by the OS. Consider using a lock to ensure thread-safety:

private readonly object _slaveLock = new(); public void CloseSlave() { lock (_slaveLock) { if (!_slaveFdClosed) { NativeMethods.Unix.Close(_slaveFd); _slaveFdClosed = true; } } }

The same protection should be applied in the Dispose() method when closing the slave fd.

Resolved -- CloseSlave() now uses a Lock to prevent concurrent double-close.

Copilot · 2025-12-09T09:37:06Z

CliWrap/Utils/UnixPseudoTerminal.cs

+            _masterStream = new UnixFdStream(_masterFd, canRead: true, canWrite: true);
+        }
+        catch
+        {
+            // Clean up fds if initialization fails after openpty
+            NativeMethods.Unix.Close(_masterFd);
+            NativeMethods.Unix.Close(_slaveFd);
+            throw;


If the UnixFdStream constructor (line 52) fails, the exception handler will call Close() on _masterFd. However, since UnixFdStream was already created with _masterFd, its Dispose() method will also try to close the same fd, leading to a double-close. The UnixFdStream.Dispose() takes ownership of the fd, so you should not close it again in the exception handler. Remove the Close(_masterFd) call from the catch block:

catch { // Only close slave - UnixFdStream hasn't taken ownership if it failed to construct NativeMethods.Unix.Close(_slaveFd); throw; }

Actually, review this more carefully - if UnixFdStream constructor throws before completion, it won't dispose the fd, so you may need to track whether the stream was successfully created.

Resolved -- the catch block now tracks masterStreamCreated and only closes _masterFd if the stream hasn't taken ownership of it.

CliWrap/Utils/WindowsPseudoTerminal.cs

Copilot · 2025-12-09T09:37:06Z

CliWrap/Utils/UnixFdStream.cs

+        var bytesRead = NativeMethods.Unix.Read(_fd, ref buffer[offset], (nuint)count);
+
+        if (bytesRead < 0)
+        {
+            var error = Marshal.GetLastWin32Error();
+            // Retry if interrupted by signal
+            if (error == NativeMethods.Unix.EINTR)
+                return Read(buffer, offset, count);
+
+            throw new IOException(
+                $"Failed to read from file descriptor {_fd}. Error code: {error}"
+            );
+        }
+
+        return (int)bytesRead;


The recursive call to Read() when EINTR error occurs can potentially cause a stack overflow if signals are repeatedly interrupting the read operation. Consider using a loop instead of recursion to handle EINTR retries.

Example fix:

while (true) { var bytesRead = NativeMethods.Unix.Read(_fd, ref buffer[offset], (nuint)count); if (bytesRead < 0) { var error = Marshal.GetLastWin32Error(); if (error == NativeMethods.Unix.EINTR) continue; // Retry throw new IOException($"Failed to read from file descriptor {_fd}. Error code: {error}"); } return (int)bytesRead; }

Suggested change

var bytesRead = NativeMethods.Unix.Read(_fd, ref buffer[offset], (nuint)count);

if (bytesRead < 0)

{

var error = Marshal.GetLastWin32Error();

// Retry if interrupted by signal

if (error == NativeMethods.Unix.EINTR)

return Read(buffer, offset, count);

throw new IOException(

$"Failed to read from file descriptor {_fd}. Error code: {error}"

);

}

return (int)bytesRead;

while (true)

{

var bytesRead = NativeMethods.Unix.Read(_fd, ref buffer[offset], (nuint)count);

if (bytesRead < 0)

{

var error = Marshal.GetLastWin32Error();

// Retry if interrupted by signal

if (error == NativeMethods.Unix.EINTR)

continue;

throw new IOException(

$"Failed to read from file descriptor {_fd}. Error code: {error}"

);

}

return (int)bytesRead;

}

Resolved -- replaced recursion with a while loop that uses continue on EINTR.

Copilot · 2025-12-09T09:37:30Z

CliWrap.Tests/PseudoTerminalSpecs.cs

+
+        for (var i = 0; i < taskCount; i++)
+        {
+            outputs[i] = new StringBuilder();


Creating a 'StringBuilder' in a loop.

CliWrap.Tests/PseudoTerminalSpecs.cs

CliWrap/Utils/PtyProcessEx.cs

…rminal implementations

Tyrrrz

Thank you for the PR! Left some comments. Copilot also left some good ones too.

CliWrap.Tests/PseudoTerminalSpecs.cs

CliWrap/Builders/PseudoTerminalOptionsBuilder.cs

CliWrap/Utils/PseudoTerminal.cs

CliWrap/Utils/NativeMethods.Windows.cs

CliWrap/Utils/PtyProcessEx.cs

CliWrap/Command.cs

CliWrap/Command.Execution.cs

CliWrap.Tests/PseudoTerminalSpecs.cs

…tionality with platform-specific methods

…xecution

…rocessEx and UnixPseudoTerminal

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

CliWrap/Command.Execution.cs

Tyrrrz · 2025-12-11T10:31:51Z

CliWrap/Command.Execution.cs

+            // Flush to ensure data is sent to the PTY immediately
+            await process.StandardInput.FlushAsync(cancellationToken).ConfigureAwait(false);
+        }
+        catch (IOException ex) when (ex.GetType() == typeof(IOException)) { }


Can you please add comments describing when each ignored exception type can happen and why we're ignoring them. Same for the PipePtyOutputAsync method.

Done -- both PipePtyInputAsync and PipePtyOutputAsync now have comments above the catch clause explaining each exception type: IOException (PTY closed/pipe broken during process termination), ObjectDisposedException (stream disposed during cleanup), and OperationCanceledException (cancellation requested).

…inalSpecs feat: Implement asynchronous ReadAsync and WriteAsync methods in UnixFdStream

…to feature/225

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Tyrrrz · 2025-12-19T19:40:47Z

Currently failiing on these two tests: https://github.com/Tyrrrz/CliWrap/actions/runs/20142129317?pr=309

- Fix ParseArguments to handle escaped quotes (fixes special characters test) - Use SIGINT directly on Unix for reliable interrupt signal delivery (fixes Ctrl+C test) - Close master fd in child process to prevent fd leaks (fixes concurrent execution issues) - Implement CloseConsole on Unix to properly signal EOF and unblock reads - Fix potential double-dispose of master stream with proper state tracking

- Add SIGINT and SIGKILL constants to NativeMethods.Unix, replacing magic numbers - Fix WindowsPseudoTerminal dimension validation to check >= 1 instead of >= short.MinValue - Add error checking for posix_spawnattr_setflags return value - Document shared stream behavior on Unix (InputStream/OutputStream are same fd) - Document working directory race condition limitation with posix_spawn

thomhurst · 2026-01-19T01:36:23Z

Sorry lost track of this one! Just pushed some updates

JasonLandbridge · 2026-02-10T17:35:42Z

Awesome work! Just happen to run into needing this

@Tyrrrz Could you please take a look again?

Tyrrrz · 2026-02-10T18:27:59Z

Hi there. I will take a look as soon as I can. Currently really busy with IRL stuff.

Copilot

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 3 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-14T16:18:52Z

CliWrap/Utils/WindowsPseudoTerminal.cs

+        catch
+        {
+            _inputWriteHandle.Dispose();
+            _outputReadHandle.Dispose();
+            NativeMethods.Windows.ClosePseudoConsole(_pseudoConsoleHandle);
+            throw;
+        }


In the exception handler at lines 94-100, handles may be disposed twice if one FileStream construction succeeds but the other fails. When FileStream is constructed with a SafeFileHandle, it takes ownership by default. If _inputStream is successfully created (line 81-86) but _outputStream creation throws (line 87-92), then _inputWriteHandle is already owned by _inputStream. The subsequent disposal at line 96 attempts to dispose a handle that's already owned by the FileStream, which could cause issues.

Consider tracking which streams were successfully created and only disposing handles that weren't transferred to a FileStream, or wrap each FileStream construction in a separate try-catch block.

Resolved -- the catch block now checks whether _inputStream was successfully created. If so, it disposes the stream (which owns the handle) instead of disposing the handle directly.

Copilot · 2026-02-14T16:18:52Z

CliWrap/Command.Execution.cs

+    private CommandTask<CommandResult> ExecuteWithPtyAsync(
+        CancellationToken forcefulCancellationToken,
+        CancellationToken gracefulCancellationToken
+    )
+    {
+        // Create pseudo-terminal
+        var pty = PseudoTerminal.Create(PseudoTerminalOptions.Columns, PseudoTerminalOptions.Rows);
+
+        var process = new PtyProcessEx(
+            pty,
+            GetOptimallyQualifiedTargetFilePath(),
+            Arguments,
+            WorkingDirPath,
+            CreateEnvironmentBlock()
+        );
+
+        process.Start();
+
+        var processId = process.Id;
+
+        return new CommandTask<CommandResult>(
+            ExecuteAsync(process, forcefulCancellationToken, gracefulCancellationToken),
+            processId
+        );
+    }


The PTY execution path does not support Credentials or ResourcePolicy that are configured on the Command. When PTY mode is enabled, these settings are silently ignored. This should be documented in the WithPseudoTerminal methods' remarks section, or the code should validate and throw an exception if these are set when PTY is enabled. Users might expect these features to work with PTY and could be surprised when their credentials or resource policies are not applied.

Acknowledged -- this is a known limitation of the PTY path. Credentials and ResourcePolicy require System.Diagnostics.Process APIs that are not available when using native process creation (CreateProcessW / posix_spawn). The PseudoTerminalOptions docs note that PTY uses a different execution path. Could add explicit validation to throw if these are set with PTY enabled, if preferred.

Hmm, I wonder if it would be better that, instead of the IProcessEx abstraction (or maybe in addition to), we make ICommand with Command and PtyCommand.

PtyCommand would not have the configuration methods that it doesn't support. It would also not have any configuration for StandardError pipes (for the interface, it could still explicitly implement it, but hide it in the actual class).

The execution models such as ExecuteBufferedAsync() would probably work just fine off the ICommand interface.

Copilot · 2026-02-14T16:18:52Z

CliWrap/Command.Execution.cs

+        // Start piping streams in the background
+        // With PTY, stderr is merged into stdout, so we only pipe stdin and stdout
+        var pipingTask = Task.WhenAll(
+            PipePtyInputAsync(process, stdInCts.Token),
+            PipePtyOutputAsync(process, stdOutCts.Token)
+        );


When PTY mode is enabled, StandardErrorPipe is completely ignored and never receives any data or EOF signal. This could cause issues if the pipe target expects to be notified of stream completion. Consider piping an empty stream to StandardErrorPipe (e.g., Stream.Null) to ensure the target completes properly, or document this behavior more explicitly. The test at PseudoTerminalSpecs.cs:381 verifies stderr buffer is empty, but this only works because StringBuilder doesn't block - other pipe targets might behave differently.

Acknowledged -- this is by design since PTY merges stderr into stdout at the terminal level. The PseudoTerminalOptions docs state this: "When PTY is enabled, stderr is merged into stdout on all platforms. The StandardErrorPipe will receive an empty stream." The existing test verifies this behavior. Piping Stream.Null to StandardErrorPipe could be added for completeness if desired.

To that end, I think we should indeed pipe an empty (Stream.Null) stream to stderr to explify emptiness, rather than just leave it idle

… overflow The Unix PTY had no validation before casting int to ushort in SetSize() and the constructor, so values > 65535 would silently overflow. This adds ValidateDimensions matching the Windows side's pattern. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…y fails If _inputStream was successfully created (taking ownership of _inputWriteHandle) but _outputStream creation throws, dispose the stream instead of the handle directly to avoid double-dispose. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Tyrrrz

Sorry for a long delay, got a lot of work outside of OSS and I keep putting off these 3000+ line changes 🥲

Didn't get to read through everything, but added some comments to unblock the PR

Tyrrrz · 2026-03-03T16:37:58Z

CliWrap/Command.cs

+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// PTY mode makes CLI applications behave as if running in an interactive terminal,


Suggested change

/// PTY mode makes CLI applications behave as if running in an interactive terminal,

/// Pseudo-terminal (PTY) mode makes CLI applications behave as if running in an interactive terminal,

Tyrrrz · 2026-03-03T16:40:02Z

CliWrap/Command.cs

+    /// </para>
+    /// </remarks>
+    [Pure]
+    public Command WithPseudoTerminal(bool enabled = true) =>


Suggested change

public Command WithPseudoTerminal(bool enabled = true) =>

public Command WithPseudoTerminal(bool isEnabled = true) =>

Tyrrrz · 2026-03-03T16:40:50Z

CliWrap/Command.cs

+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// PTY mode makes CLI applications behave as if running in an interactive terminal,


Suggested change

/// PTY mode makes CLI applications behave as if running in an interactive terminal,

/// Pseudo-terminal (PTY) mode makes CLI applications behave as if running in an interactive terminal,

Tyrrrz · 2026-03-03T16:42:53Z

CliWrap/Command.Execution.cs

+            // IOException (exact type only): "The pipe has been ended" (Windows) or "Broken pipe" (Unix).
+            // This occurs when the process terminates before consuming all stdin data - not an error
+            // since the process may not need all input to complete successfully.
+            // Don't catch derived exceptions (e.g., FileNotFoundException) to avoid masking real errors.


Restore the original comment since it was rewritten

Suggested change

// IOException (exact type only): "The pipe has been ended" (Windows) or "Broken pipe" (Unix).

// This occurs when the process terminates before consuming all stdin data - not an error

// since the process may not need all input to complete successfully.

// Don't catch derived exceptions (e.g., FileNotFoundException) to avoid masking real errors.

// Expect IOException: "The pipe has been ended" (Windows) or "Broken pipe" (Unix).

// This may happen if the process terminated before the pipe has been exhausted.

// It's not an exceptional situation because the process may not need the entire

// stdin to complete successfully.

// Don't catch derived exceptions, such as FileNotFoundException, to avoid false positives.

// We also can't rely on process.HasExited here because of potential race conditions.

Tyrrrz · 2026-03-03T16:45:18Z

CliWrap/Command.Execution.cs

+        try
+        {
+            // Read in a loop and pipe to output target
+            var buffer = new byte[4096];


Should be able to use MemoryPool here and pass Memory to ReadAsync

Tyrrrz · 2026-03-03T17:11:17Z

CliWrap/PseudoTerminalOptions.cs

+    /// <summary>
+    /// Default PTY options (disabled).
+    /// </summary>
+    public static PseudoTerminalOptions Default { get; } = new();


Should probably rename to:

Suggested change

public static PseudoTerminalOptions Default { get; } = new();

public static PseudoTerminalOptions Disabled { get; } = new();

Tyrrrz · 2026-03-03T17:12:04Z

CliWrap/Builders/PseudoTerminalOptionsBuilder.cs

+    /// <remarks>
+    /// Default is <c>true</c> when using the builder.
+    /// </remarks>
+    public PseudoTerminalOptionsBuilder SetEnabled(bool enabled = true)


Suggested change

public PseudoTerminalOptionsBuilder SetEnabled(bool enabled = true)

public PseudoTerminalOptionsBuilder SetEnabled(bool isEnabled = true)

Tyrrrz · 2026-03-03T17:12:23Z

CliWrap.Tests/PseudoTerminalSpecs.cs

+        || OperatingSystem.IsLinux()
+        || OperatingSystem.IsMacOS();
+
+    #region Configuration Tests - Default Values


Let's drop regions. If it feels like we have so many tests that we need regions, we probably have many redundat tests.

Tyrrrz · 2026-03-03T17:12:52Z

CliWrap.Tests/PseudoTerminalSpecs.cs

+    #region Configuration Tests - Default Values
+
+    [Fact]
+    public void PseudoTerminalOptions_has_correct_default_values()


Generally, we can move all configuration-related tests to ConfigurationSpecs. See the existing tests there for inspiration. There shouldn't be too many tests.

Tyrrrz · 2026-03-03T17:14:25Z

CliWrap.Tests/PseudoTerminalSpecs.cs

+    }
+
+    [Fact]
+    public void Builder_SetEnabled_defaults_to_true()


Definitely drop tests like these

thomhurst added 4 commits December 9, 2025 08:39

feat: Add support for pseudo-terminal (PTY) mode in CLI commands

29c7c73

fix: Improve error handling in PtyProcessEx.Kill method

a1e66fc

feat: Enhance pseudo-terminal functionality with improved error handl…

d4d7ef9

…ing and validation

refactor: Simplify cancellation token usage in CancellationSpecs tests

841726c

Copilot AI review requested due to automatic review settings December 9, 2025 09:21

Copilot started reviewing on behalf of thomhurst December 9, 2025 09:21 View session

Copilot AI reviewed Dec 9, 2025

View reviewed changes

refactor: Improve error handling and resource management in pseudo-te…

243bf86

…rminal implementations

Tyrrrz added the enhancement label Dec 9, 2025

Tyrrrz changed the title ~~feat: Add support for pseudo-terminal (PTY) mode in CLI commands~~ Add support for pseudo-terminal (PTY) mode in CLI commands Dec 9, 2025

Tyrrrz reviewed Dec 9, 2025

View reviewed changes

thomhurst and others added 4 commits December 10, 2025 19:05

feat: Implement IProcessEx interface and enhance pseudo-terminal func…

b8e3e07

…tionality with platform-specific methods

feat: Add cancellation and exit code validation methods for process e…

764d2c6

…xecution

refactor: Replace object with Lock for thread-safe operations in PtyP…

3eb2e12

…rocessEx and UnixPseudoTerminal

Apply suggestions from code review

1698bc0

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Tyrrrz reviewed Dec 11, 2025

View reviewed changes

thomhurst and others added 4 commits December 11, 2025 12:29

refactor: Reduce timeout values for SkippableFact tests in PseudoTerm…

c02cd85

…inalSpecs feat: Implement asynchronous ReadAsync and WriteAsync methods in UnixFdStream

Merge branch 'feature/225' of https://github.com/thomhurst/CliWrap in…

d92ffd0

…to feature/225

Update CliWrap/Command.Execution.cs

e5408d5

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Apply suggestions from code review

45fc746

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

thomhurst added 2 commits January 19, 2026 01:23

Tyrrrz requested a review from Copilot February 14, 2026 16:12

Copilot started reviewing on behalf of Tyrrrz February 14, 2026 16:12 View session

Copilot AI reviewed Feb 14, 2026

View reviewed changes

Tyrrrz reviewed Mar 3, 2026

View reviewed changes

	/// PTY mode makes CLI applications behave as if running in an interactive terminal,
	/// Pseudo-terminal (PTY) mode makes CLI applications behave as if running in an interactive terminal,

	public Command WithPseudoTerminal(bool enabled = true) =>
	public Command WithPseudoTerminal(bool isEnabled = true) =>

-            // IOException (exact type only): "The pipe has been ended" (Windows) or "Broken pipe" (Unix).
-            // This occurs when the process terminates before consuming all stdin data - not an error
-            // since the process may not need all input to complete successfully.
-            // Don't catch derived exceptions (e.g., FileNotFoundException) to avoid masking real errors.
+            // Expect IOException: "The pipe has been ended" (Windows) or "Broken pipe" (Unix).
+            // This may happen if the process terminated before the pipe has been exhausted.
+            // It's not an exceptional situation because the process may not need the entire
+            // stdin to complete successfully.
+            // Don't catch derived exceptions, such as FileNotFoundException, to avoid false positives.
+            // We also can't rely on process.HasExited here because of potential race conditions.

	public static PseudoTerminalOptions Default { get; } = new();
	public static PseudoTerminalOptions Disabled { get; } = new();

	public PseudoTerminalOptionsBuilder SetEnabled(bool enabled = true)
	public PseudoTerminalOptionsBuilder SetEnabled(bool isEnabled = true)

Uh oh!

Conversation

thomhurst commented Dec 9, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Tyrrrz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tyrrrz commented Dec 19, 2025

Uh oh!

thomhurst commented Jan 19, 2026

Uh oh!

JasonLandbridge commented Feb 10, 2026

Uh oh!

Tyrrrz commented Feb 10, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment