This issue proposes two concrete amendments to the CAP specification, both derived from real‑world headless / remote Agent scenarios.
1. OSC‑52 based semantic copying for headless remote sessions
Problem
In headless SSH containers or servers without a graphical clipboard (X11/Wayland absent), traditional clipboard APIs (arboard, xclip) fail. Overriding mouse selection for copy is intrusive and breaks user muscle memory.
Proposed change
Add an optional OSC‑52 escape‑based copy mechanism to CAP (physical copy section). It follows a two‑track principle:
- 100% respect native selection – never steal or emulate mouse events.
- On demand (via hit‑testing +
LayoutRect coordinates), extract clean plain‑text content from the semantic snapshot, base64‑encode it, and emit an OSC 52 escape sequence to the terminal.
Rationale
Makes “copy from a headless Agent UI” work without custom clipboard binaries, browser extensions, or host‑side daemons.
Non‑goal
This does not replace system clipboard APIs where available. It is a fallback for environments where they are absent.
2. Formal DDoS mitigation and zero‑panic boundaries (insert as §3.1.1 or a new “Safety Boundaries” section)
Problem
An Agent can push arbitrarily large semantic snapshots (thousands of nodes, multi‑megabyte content). Without hard limits, the client is exposed to OOM, panic attacks, or accidental crashes.
Proposed change
Add a mandatory “Safety Boundaries” section to the CAP specification:
Inbound constraints (client‑side)
- Max 256 semantic nodes per snapshot. Excess → client MAY truncate or reject the snapshot.
- Single node
content size ≤ 1 MB. Larger → client MUST degrade that node’s type to NodeType::Unknown (or discard it) to avoid memory explosion.
Outbound constraints (agent‑side)
- Agents SHOULD respect the same limits before pushing.
Fail‑closed principle
- All CAP parsers MUST gracefully degrade when limits are exceeded: no
panic, no crash, no uncontrolled memory allocation.
Rationale
Prevents memory exhaustion and increases resilience for long‑running, unattended clients (e.g., embedded systems, headless servers). These limits are not meant to be future‑proof forever but provide a safe baseline.
Next steps
Both proposals have been validated in the reference Rust implementation (Cellrix). They will be kept as internal design notes until further cross‑component testing completes. This issue serves as the permanent record.
/cc @Jasonmilk
This issue proposes two concrete amendments to the CAP specification, both derived from real‑world headless / remote Agent scenarios.
1. OSC‑52 based semantic copying for headless remote sessions
Problem
In headless SSH containers or servers without a graphical clipboard (X11/Wayland absent), traditional clipboard APIs (
arboard,xclip) fail. Overriding mouse selection for copy is intrusive and breaks user muscle memory.Proposed change
Add an optional OSC‑52 escape‑based copy mechanism to CAP (physical copy section). It follows a two‑track principle:
LayoutRectcoordinates), extract clean plain‑text content from the semantic snapshot, base64‑encode it, and emit an OSC 52 escape sequence to the terminal.Rationale
Makes “copy from a headless Agent UI” work without custom clipboard binaries, browser extensions, or host‑side daemons.
Non‑goal
This does not replace system clipboard APIs where available. It is a fallback for environments where they are absent.
2. Formal DDoS mitigation and zero‑panic boundaries (insert as §3.1.1 or a new “Safety Boundaries” section)
Problem
An Agent can push arbitrarily large semantic snapshots (thousands of nodes, multi‑megabyte
content). Without hard limits, the client is exposed to OOM, panic attacks, or accidental crashes.Proposed change
Add a mandatory “Safety Boundaries” section to the CAP specification:
Inbound constraints (client‑side)
contentsize ≤ 1 MB. Larger → client MUST degrade that node’s type toNodeType::Unknown(or discard it) to avoid memory explosion.Outbound constraints (agent‑side)
Fail‑closed principle
panic, no crash, no uncontrolled memory allocation.Rationale
Prevents memory exhaustion and increases resilience for long‑running, unattended clients (e.g., embedded systems, headless servers). These limits are not meant to be future‑proof forever but provide a safe baseline.
Next steps
Both proposals have been validated in the reference Rust implementation (Cellrix). They will be kept as internal design notes until further cross‑component testing completes. This issue serves as the permanent record.
/cc @Jasonmilk