v0.8.16

Patch release whose Aider, Open Interpreter and Goose adapters read the questions those agents actually ask, captured from real sessions, and answer with bytes observed to do what they say. Goose's deny, n and Enter, would have allowed the tool call on Goose's real menu; it now picks Deny. A web gateway can keep the agents' terminals from its viewers with --viewer-terminals hidden, and a keystroke to an agent that reads nothing now gives up after five seconds on macOS, the BSDs and Windows as it did on Linux.

Fixed

• The Aider adapter read the questions Aider asks, not questions it was guessed to ask. Its patterns were written by hand from documentation and never checked against Aider. Captured from Aider 0.86.2 in a PTY, against a stand-in model and a disposable repository, half of them turned out to be questions Aider never asks ("Apply changes?", "Commit changes?", "Push to remote?", "Add files to git?"), while "Add .aider* to .gitignore (recommended)?" went undetected and "Add command output to the chat?" and "Allow edits to file that has not been added to the chat?" were both reported as adding a file to the chat, the second one a file edit shown as a low-risk question. The adapter now reads the six questions captured, each answered with y and Enter and with n and Enter and its side effect checked, and nothing else: an Aider question not among them falls back to the configured intercept_patterns. The fixtures are in internal/adapters/testdata/aider.
• The Open Interpreter adapter read the questions Open Interpreter asks. Its patterns were written by hand from documentation. Captured from Open Interpreter 0.4.3 in a PTY, against a stand-in model, it asks two questions, "Would you like to run this code? (y/n)" and, under --safe_mode ask, "Would you like to scan this code? (y/n)", and nothing before installing a package or saving a file; the hand-written "run the following code" and "run this command" wordings were never printed. It also prints the question, then two line breaks and the indentation it reads the answer on: written in one piece, the question was two lines above the line the adapter looked at, and was seen only when a repaint happened to precede it. The adapter now reads the two captured questions, each answered with y and Enter and with n and Enter and its side effect checked, on the line above the answer line too. The fixtures are in internal/adapters/testdata/interpreter.
• The Goose adapter's deny would have allowed the tool call. Its patterns were written by hand from documentation, as (y/n) questions answered with y or n and Enter. Captured from Goose 1.52.0 in a PTY, against a stand-in model, Goose asks no such question: it asks before a tool call with a menu (Allow, Always Allow, Deny, Cancel), where y and n do nothing and Enter picks the highlighted option, Allow. n and Enter was observed to run the command. None of the patterns matched Goose's output, so the adapter never sent it, and no Goose question was ever detected either. The adapter now reads the two menus Goose draws, "Goose would like to call the above tool, do you allow?" and "Do you allow this tool call?" (drawn when a check attached a notice, as for extension management), in Unicode and ASCII, and answers with the keys that pick Allow or Deny wherever the highlight is: k to the top, j down, Enter. Each answer was typed into Goose and its effect checked. Manual input names allow, deny or cancel. The fixtures are in internal/adapters/testdata/goose.
• A question drawn over several lines could be lost when a read ended inside a line break or a character. Before the screen took over detection, a read that ended between the \r and the \n of a line break erased the line it ended, and one that ended inside a UTF-8 character had its bytes replaced. Goose's menu read a byte at a time left nothing of itself to detect. The detection window now holds either back for the next read.
• A web keystroke to an agent that reads nothing could block for good on macOS, the BSDs and Windows. Once such an agent's terminal input buffer is full, a write waits for room. On Linux the gateway's keystrokes gave up after five seconds; elsewhere the write blocked until the agent read again or exited, and held the session's write slot, and the run's end, with it. On macOS and the BSDs the terminal is now written through the runtime's poller, as on Linux, which the five-second bound and a Stop both end; on Windows a timer cancels a console write still blocked at its deadline. TestAKeystrokeWriteToAnAgentThatReadsNothingEndsWithItsContext now runs on macOS, and TestAKeystrokeWriteToAWindowsAgentThatReadsNothingEndsWithItsContext on Windows.

Added

• relayer serve --viewer-terminals hidden keeps the agents' terminals from viewers. A viewer token was a token to read every terminal: the snapshots carry each screen verbatim, so a secret an agent echoed reached every viewer, and the only choice was not to hand viewer tokens out. With the option, a viewer's state and snapshots carry each agent's status, exit code and prompt card but no output, a recording's contents are refused to it, and its interface says why in place of each terminal. Operators are unaffected, and the default, shown, keeps the behaviour as it was.

Full commit list: v0.8.15...v0.8.16