Write access

A read-only session is not a permanent state. You can hand over the keyboard mid-session and take it back, which is what pairing usually looks like in practice: watch, watch, "here, you try", watch again.

Granting it

Press Ctrl+] w. The viewer can type. Press Ctrl+] r and they cannot, immediately.

That is the whole mechanism. Everything below is about not having to be at the keyboard to say yes.

When the viewer asks

A viewer can request write access — from the browser viewer's button, or with porthole join --write. By default the request appears on your terminal and waits for you.

# Approve every request the moment it arrives.
porthole host --readonly --auto-approve

# Grant for 10 minutes at a time, then drop back to read-only.
porthole host --readonly --auto-approve --request-duration 10m

# Refuse requests outright — no prompt, no button.
porthole host --readonly --no-requests

--request-duration 0 (the default) means the grant lasts until the session ends or you revoke it.

These flags only mean anything with --readonly. In a default writable session the viewer can already type, so there is nothing to request and nothing to approve.

Revocation is immediate

Ctrl+] r takes effect at once. Keystrokes the viewer already sent that are still queued are discarded rather than delivered.

This is worth stating precisely, because the obvious implementation would not do it. Permission is checked twice: when input is accepted, and again in the writer goroutine immediately before it reaches the shell. Input sits in a queue in between, and a viewer can control how long by stalling the shell — so a check made only on arrival would let revoked keystrokes still run. The second check is the one that enforces the boundary.

A grant survives reconnection

If the network drops and the viewer comes back, a grant that was in force is restored, and it is restored only for the peer it was issued to. A grant is not a property of the session that whoever connects next inherits.

Timed grants keep their original deadline across a reconnect — reconnecting is not a way to buy more time.

What revoking does not do

Revoking input does not un-see anything. The viewer has already been shown everything on screen up to that moment, and may have recorded it. If the concern is what they can read rather than what they can type, the tools are credential masking and ending the session.

The host is never locked out

--readonly and every revocation apply to the viewer. Your own keystrokes take a separate path with no permission check at all, so there is no state in which Porthole stops you typing into your own shell.