Puts text on the desktop’s clipboard, ready to paste. Pair it with POST /computers/{id}/input sending ctrl+v to get the text into whatever has focus — this call alone leaves it on the clipboard and touches nothing on screen.

Unlike the read, this DRIVES the computer: a suspended one is resumed to serve it, which is a start and is charged like one.

At most 64 KiB goes in — half the read cap, and the difference is not taste. The text travels to the guest inside one argument of one command, and Linux caps a single argument at 128 KiB; two layers of base64 stand between your text and that ceiling, so each byte costs about 1.8 of it. Anything larger is a 413.

A NUL byte is refused, because the write is confirmed through a shell and a shell truncates at the first one — so it would land and then be reported as never having landed.

Empty text CLEARS the clipboard, and it is the only way to say that. Sending "" leaves the desktop holding nothing; sending something else is not a clear, it is a different secret in the same place. Omitting text altogether is still a 400 — an absent field is a malformed request, an empty one is an instruction.

Two other 400s here NEVER clear, and they are the ones not to retry. The guest needs xclip (X11) or wl-clipboard (Wayland) in its image — every golden built since August 2026 has it, so this is a computer created before then, and a computer keeps the image it was created from; install that tool in the guest, which you can do since you have root there, or create a new computer from an image that includes it. And Windows guests are refused outright. Both say which they are, and both carry reason: "unsupported" — the word for a refusal no action on the computer changes. This matters more on this operation than on the read, because the 409 advice below tells you to retry some failures and neither of these is one of them.

The write is confirmed by reading the selection back rather than by an exit status, so a 200 here means the desktop is holding your text, not merely that a command ran.

Not every 409 here is worth retrying, and reason in the body is how you tell. contention is the one that clears by itself — "the desktop did not take the text" means something else claimed the selection in that instant, a clipboard manager settling, usually — and starting means the guest agent has not answered inside its boot window yet, which clears too, just more slowly. Desktop-session and X-server failures are deliberately unclassified because they can also mean nobody is logged in, the window manager crashed, or the display remains unreachable; an absent reason gives no retry advice. unavailable is the one that does not: the computer is not running, and starting it is the fix rather than another attempt. Branch on that word and never on the sentence, which is prose and is rewritten. A blanket retry on 409 spins until your deadline against a computer that is simply stopped, spending your request allowance a turn at a time and never coming good.

Requires the member role or higher.