解决什么问题
gh auth login、ssh-copy-id、npm publish、npm login 这些命令默认是交互式的，默认有一个 Terminal, 是人坐在终端前面：选 GitHub.com 还是 Enterprise 、按 y/n 、粘贴 token 、输入密码……
放到 AI agent 场景就很尴尬：agent 在 sandbox 里跑 bash/exec，碰到这种交互，agent 直接卡住。常见的 workaround：
noni 的思路是把这件事变成一系列无状态 RPC 调用：
agent: noni run "gh auth login"
noni: {id: abc, status: waiting_input, prompt: {type: select, options: [...]}}
agent: noni key abc enter
noni: {id: abc, status: waiting_input, prompt: {type: yesno, default: "y"}}
agent: noni input abc Y
noni: {id: abc, status: waiting_input, prompt: {type: password, echo: false}}
agent: noni secret abc --env GH_TOKEN
noni: {id: abc, status: exited, exit_code: 0}
agent 看到的是结构化的 prompt，也可以用 read --raw 来读这屏幕，然后自己决定下一步发什么。这样整个工具调用流程不会卡住。
几个设计细节
[ol]
prompt 类型靠几个不同信号判断：
noni secret --env VAR —— token 不走 RPC wire 。读的是 daemon 进程的环境变量，所以不会出现在 agent 的 prompt / 日志 / context 里。这是协议层的硬保障，不是约定。
架构是 stateless CLI + 常驻 daemon：
noni (CLI) ──JSON-RPC over Unix socket──▶ nonid (daemon) ──PTY──▶ child
socket 在 $XDG_RUNTIME_DIR/noni/sock，0600 。daemon 由 CLI 首次调用时自动 spawn 。
终端模拟用 hinshun/vt10x，detector 看的是"稳定后的虚拟屏幕"而不是原始字节流，避免被光标移动 / 重绘干扰。
[/ol]
实测
让 agent 在容器里跑 gh auth login 整个 device flow 是能走通的（用户授权那一步还是要人）。完整一次跑下来 14 个 RPC 调用，包括 3 次 select（ host / protocol / method ）、1 次 yesno（是否用 git credentials ）、最后 enter 等待 device 授权完成。
安装
brew install williamwa/tap/noni
# 或
go install github.com/williamwa/noni/cmd/noni@latest
go install github.com/williamwa/noni/cmd/nonid@latest
Linux 主测，macOS 能跑。
Go 单文件，无运行时依赖。还在 v0.1.0-dev ，欢迎拍砖 / issue / PR：
👉 https://github.com/williamwa/noni
