Skip to content

Fleet Deck

v0.20.0 Bugfix

This release fixes issues for SREs watching stability and regressions.

✓ No known CVEs patched
Read the diff → Tool health → What is this tool? →

✓ No known CVEs patched in this version

Topics

agents ai-agents claude claude-code claude-code-plugin web
+4 more
developer-tools multi-agent orchestration tmux

Summary

AI summary

Ctrl+V now pastes clipboard text instead of sending ^V, fixing several clipboard‑related bugs.

Full changelog

Copying out of a live pane, and pasting into one, now actually reach your clipboard. A minor rather than a patch: Ctrl+V no longer delivers ^V to the program in a pane, and the board gained clipboard capability (OSC 52) it never had.

Fixed

  • The agent's own copy now reaches your clipboard. This is the one that was broken all along. Claude Code's TUI turns mouse reporting on, so a drag across a pane never reaches the emulator as a selection: the TUI does its own selecting, prints its own "copied N characters", and writes the clipboard with OSC 52 — the terminal's clipboard escape — wrapped for tmux passthrough. Two things then threw it away. tmux hands Fleet Deck that wrapper unopened, because our client is tmux control mode, which is not a terminal and so never gets the unwrapping a real client would; and xterm has no OSC 52 handler at all (0, 1, 2, 4, 8, 10–12, 104, 110–112 — and that is the whole table). So the agent reported a copy, the terminal discarded it, and the clipboard kept whatever was in it. The board now does tmux's half of the job and honours the write.

    Writes only, never reads. OSC 52 has a read form that answers by typing the clipboard back into the pane as though you had pasted it, and any byte a pane renders — a file, a tool result, a fetched page — can ask for it. It is refused, with a test pinning the refusal. Only the clipboard write is unwrapped from a passthrough; every other passthrough sequence is dropped rather than forwarded to the emulator.

  • Ctrl+V pastes your clipboard into the pane. In a terminal Ctrl+V is not paste — it is the byte ^V, and pasting is Ctrl+Shift+V. That convention assumes the terminal and the program share a machine. Here they do not: your clipboard is in a browser, possibly on another computer, and Claude Code answers ^V by looking for an image on the daemon host's clipboard and reporting "no image found" — truthful, and about the wrong machine. The board now claims the chord and lets the browser perform its own paste, which needs no clipboard permission and still goes through xterm's bracketing, so a multi-line paste cannot submit itself line by line. Ctrl+Shift+V, right-click → Paste and ⌘V are unchanged.

  • "✓ copied" now means the clipboard actually changed. The pane reported success from the return value of a clipboard call, and neither call means what it looks like: navigator.clipboard.writeText() resolves when the write is accepted — Chrome can drop it afterwards, with no callback — and document.execCommand('copy') returns true for "the command ran". A copy is now driven through a real copy event whose listener writes the data, and it is the listener firing that gets reported. A refused copy keeps the selection on screen, because right-click → Copy is then the remaining path and it needs one.

  • A drag that cannot select now says why, where it failed. The agent's TUI owns a plain drag, so it selects nothing. That fact used to live in a header hint, which is the same as nowhere. A sweep across a pane that selects nothing now answers itself: ⇧drag to select — the agent owns a plain drag (⌥ on a Mac). It fires only when a modifier would genuinely have changed the outcome.

  • A terminal refused for want of the board key no longer reports a network fault. /ws/term is the one loopback route that requires the key, and the daemon refuses it by destroying the socket — so the browser cannot tell 401 from a dead network. The board rendered that as "connection closed". A socket that closes before its first frame now says which it is, and a board holding no key says so and names the fix.

  • An upgrade can no longer be invisible. index.html shipped with no cache directives at all, leaving a browser free to keep serving the previous board after an upgrade. The shell is now no-store; the fingerprinted assets are immutable.

Unchanged, and verified as such

Pasting a screenshot into a pane still uploads it to the daemon's filesystem (FLEETDECK_HOME/pastes/) and types the path into the pane — the behaviour headless and remote setups depend on, since an agent can read a file but never a clipboard. You still press Enter yourself. One improvement falls out of the Ctrl+V change: on Linux and Windows there was previously no keyboard path to paste an image (Ctrl+V was eaten as ^V, and Ctrl+Shift+V is "paste as plain text", which strips images before the page sees them). Ctrl+V now carries images too.


How this was found: three rounds of "copy still does not work" after the 0.19.2 chord shipped. The tell was in the first report — "copied xxx characters". Fleet Deck prints no character count anywhere, so that message could only have come from the agent, which meant the copy was never the board's to fix.

Known limit: an agent-initiated copy has no user gesture behind it, so it can only use navigator.clipboard — which does not exist on the plain-http LAN board. On loopback it works; from another device it does not, and Ctrl+C remains the path there.

Full changelog: https://github.com/lacion/fleet-deck/compare/v0.19.2...v0.20.0

Weekly OSS security release digest.

The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.

No spam, unsubscribe anytime.

Share this release

Track Fleet Deck

Get notified when new releases ship.

Sign up free

About Fleet Deck

All releases →

Related context

Earlier breaking changes

  • v0.13.0 Agents poller no longer uses a shell; runs via execFile with argv split on whitespace.
  • v0.6.0 Adds nullable columns `ticket`, `ticket_source`, `prev_callsign` to `sessions` table via schema migration.

Beta — feedback welcome: [email protected]