mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 00:02:23 +00:00
l0ng-ai
918b4e8313
`portable-pty` builds a signalled child's status as `code: 1` — `std::process::ExitStatus::code()` is `None` for one on Unix and its `From` impl falls back to 1 — and keeps the signal in a private field with no accessor. So `exit_code()` returns 1 and `success()` returns false for a command killed by SIGKILL *and* for one that exited 1 on its own, identically. The probe passed that straight through, which reached the CLI as `exit_code_known: true` — the field `docs/cli/reference.mdx` describes as "how you tell a real 1 from a stand-in". An agent reading it was told a killed command had chosen to exit 1. Signalled now reports unknown, which the CLI already renders as an exit of 1 *with* `exit_code_known: false` and a line on stderr. The exit code a caller sees does not change; what changes is that it is no longer claimed as the child's own. Not the `128 + n` an adopted pane gets: that path calls `waitpid` itself and has the number. Here the only thing left is a name from `strsignal`, which is localized, so mapping it back would be a guess dressed as a fact — and a wrong 137 is worse than an honest "unknown". Sniffing `Display` is the only discrimination the crate's public API offers. The test builds both cases from the crate's own constructors and asserts the exact prefix, so an upstream rewording fails there, beside the reasoning, instead of quietly turning every signalled pane back into an exit of 1. It also pins `killed.exit_code() == 1`, which is the trap.