Skip to main content

Module limits

Module limits 

Source
Expand description

The frozen limits. Every number a v1 peer is allowed to assume about the other side lives here, and nowhere else.

They are constants rather than configuration on purpose. A limit either side can tune is not a limit — it is a negotiation, and the frame that arrives while the two ends disagree is the one that gets through. Changing any of these is a protocol change: it needs a new major version, because a phone built against the old number will send a frame the daemon now refuses.

The byte counts are all measured over UTF-8 bytes, not characters. A limit counted in chars is a limit an attacker picks the units of.

Constants§

AGENT_EVENT_REPLAY_EVENTS
The most events one run keeps for replay. A run that emits faster than the window can hold drops the oldest; a client that asks for a sequence older than the buffer is told to restart from the snapshot rather than handed a gap it cannot see.
AGENT_EVENT_REPLAY_WINDOW
How far back a reconnecting client may resume an agent run’s events.
APPROVAL_EXPIRY
How long a remote approval waits for a human before it denies itself.
HEARTBEAT_INTERVAL
How often a connected daemon announces it is still there.
MAX_AGENT_PROMPT_BYTES
The largest prompt one agent turn may carry.
MAX_CLOCK_SKEW_AHEAD
How far ahead of the receiver a frame’s sentAt may be.
MAX_FRAME_BYTES
The largest frame either side will read off the socket.
MAX_INCIDENTS
The most incidents one response may carry.
MAX_INSPECTION_RESPONSE_BYTES
The ceiling on a whole inspection response, applied after per-field truncation, for the same reason MAX_LOG_RESPONSE_BYTES exists: the per-item bounds multiplied out are much larger than anything worth sending.
MAX_LOG_LINES
The most log lines one response may carry, whatever was asked for.
MAX_LOG_LINE_BYTES
Where a single log line is cut. A service that writes a megabyte without a newline must not be able to fill the frame budget by itself.
MAX_LOG_RESPONSE_BYTES
The ceiling on a whole log response, applied after per-line truncation — 200 lines of 8 KiB would otherwise be 1.6 MiB.
MAX_PENDING_COMMANDS
How many requests one device may have in flight.
MAX_PULL_REQUESTS
The most pull requests one response may carry.
MAX_REQUEST_AGE
How far in the past a frame’s sentAt may be before it is refused.
MAX_SUMMARY_BYTES
Where any single piece of prose on the inspection surface is cut — a run title, a pull request title, an incident title, a timeline detail.
MAX_TERMINAL_CHUNK_BYTES
The most raw PTY output carried in one frame, before base64.
MAX_TERMINAL_DIMENSION
The widest and tallest a mirrored terminal may claim to be. A resize is attacker-supplied arithmetic that reaches ioctl, so it is bounded before it gets there rather than trusted.
MAX_TERMINAL_INPUT_BYTES
The most keystroke data one input frame may carry.
MAX_TERMINAL_STREAMS
How many terminals one device may have mirrored at once.
MAX_TIMELINE_ENTRIES
The most timeline entries one response may carry.
MAX_WORKFLOW_JOBS
The most jobs one workflow run’s response may carry.
MAX_WORKFLOW_RUNS
The most workflow runs one response may carry, whatever was asked for.
PRESENCE_TIMEOUT
How long the platform waits before calling a device offline.
RECONNECT_BACKOFF_CAP
The ceiling on the daemon’s reconnect backoff. Jittered by the connector, so a platform restart does not bring every daemon back in the same second.
REQUEST_ID_DEDUP_WINDOW
How long a request id is remembered for duplicate detection.
SERVICE_COMMAND_TIMEOUT
How long a service action may take before the relay stops waiting.
TERMINAL_COALESCE_INTERVAL
How long the daemon gathers PTY output before sending it.