Integration idea: WinkTerm Agent API for remote terminal/SSH sessions

[Cznorth]

Summary

WinkTerm is an open-source, self-hosted terminal where AI shares the same PTY session as the user — not a separate chat panel.

Why it may be relevant here

• Human-in-the-loop terminal ops: AI writes commands to the shell input line; the user presses Enter, edits, or cancels
• In-terminal chat: type # at the prompt (no alt-tab to a sidecar)
• HTTP Agent API designed for coding agents: atomic exec with real exit_code, SSE streaming, server-side grep, one-shot SSH run
• Installable skill: curl http://<host>:8000/api/agent/skill.md — drop into Cursor / Claude Code / Continue skills directory
• BYO LLM via OpenAI-compatible endpoints; Docker one-liner deploy

Demo

• Demo GIF
• Case study: XMR cryptojacker cleanup via Agent API

Possible integration ideas

• Document WinkTerm as a remote terminal backend for agents that need shared PTY + SSH access
• Ship or link the installable skill in docs/examples
• Support driving WinkTerm sessions via existing agent workflows

Happy to help with a PR or integration testing.

[qwen-code-ci-bot]

This integration proposal appears related to ongoing discussions:

• Daemon mode (qwen serve): proposal & open decisions #3803 - Daemon mode (qwen serve): proposal & open decisions — extensive architecture discussion on HTTP API server mode, session multiplexing, and remote access patterns
• FEAT(COWORK): ADD COWORK MODE — ARTIFACT, ASKUSERQUESTION, CONNECTOR REGISTRY, COMPUTER USE #4026 - FEAT(COWORK): ADD COWORK MODE — includes terminal UX roadmap items under

Maintainers may want to evaluate whether WinkTerm's shared PTY + HTTP Agent API approach aligns with the daemon mode architecture being designed in #3803.

[LaZzyMan]

Thanks for the integration proposal — interesting framing on "AI shares the same PTY" vs sidecar agents.

Holding this open as a follow-up rather than acting on it right now. The integration surface you're describing (HTTP Agent API, atomic exec with exit_code, SSE streaming, server-side grep, one-shot SSH run) overlaps significantly with what's being built on the qwen serve daemon side (RFC #3803 and the ongoing daemon backlog #4514). Until that surface stabilizes and the long-running / non-interactive contract is firm, prematurely adopting an external integration shape would risk locking us into a transport that doesn't match the eventual one.

Reasonable path: revisit once qwen serve is past the unstable_* capability tags. If you'd like to track the daemon work in the meantime, #4514 is the rolling capability/priority matrix.

Labeling as roadmap and keeping open.