Go: stop RPC client logging expected errors

[chlowell]

You might see Error reading header: read |0: file already closed printed during client shutdown on Linux. This happens because copilot.Client kills the CLI subprocess and calls the RPC client's Stop method, which closes the subprocess's stdout. Meanwhile, the RPC client has a read loop blocked on a pipe connected to the subprocess's stdout. That loop breaks with an error: io.EOF if the process teardown wins the race, os.ErrClosed if the pipe close does. The comment anticipates this but the guard around printing the error expects only io.EOF. So, simple fix to avoid logging the expected error condition is to add os.ErrClosed to the guard.

[Copilot]

Pull request overview

Adjusts Go’s internal JSON-RPC client shutdown behavior to avoid logging an expected “closed pipe/file already closed” read error during teardown, reducing noisy stderr output when copilot.Client stops the CLI subprocess.

Changes:

• Add errors/os imports to support error classification.
• Suppress logging for read-loop header errors when the underlying error is os.ErrClosed (in addition to io.EOF).

[Copilot]

readLoop now suppresses os.ErrClosed when failing to read the header, but the message-body read path still unconditionally logs Error reading body on shutdown. Since Stop() closes stdout specifically to unblock readLoop, io.ReadFull can also return os.ErrClosed/io.EOF during normal teardown and will still print an expected error. Consider applying the same “unexpected only” guard (including c.running.Load()) to the body read error handling so shutdown stays quiet regardless of whether the loop is in header or body read.