Computer control

Everything else in Kyra happens between your phone and Kyra’s servers. This is the part that reaches your own computer: opening files in your editor, typing where your cursor is, and steering the coding-agent sessions you already have running — by voice, from another room, or from the car.

Not set up yet? Connect your computer →

The pieces

  Your phone                Kyra                    Your machine
  ──────────                ────                    ────────────

   "rename this   ──▶   works out what   ──▶   kyra connect
    symbol"             you meant                    │
                                                     ▼
                                              the local door
                                                     │
                                        ┌────────────┴────────────┐
                                        ▼                         ▼
                                   your editor            coding-agent
                                   (VS Code)                sessions

Piece	What it is
`kyra` CLI	The command you install. Holds the connection open, and carries everything else with it. Reference →
The local door	A small local process applications connect to. Started for you by `kyra connect`. Never dials the network.
A provider	The part inside an application that speaks Kyra’s protocol. The first is a VS Code extension. Your editor →
Mediation	Optional wiring that additionally lets Kyra drive the Claude Code sessions in your editor. Coding agents →

What stays on your machine

Your code, your diffs, file contents, command output, and what coding agents say. None of it goes to Kyra.

What Kyra sees is a coarse view — this session is working, this one is blocked on a question, this one has finished — plus what a session explicitly reports, and whatever you ask Kyra to do.

Coding agents run on your accounts and subscriptions. Kyra orchestrates; it is not a proxy.

Why a provider instead of controlling your screen

The obvious way to build this is to screenshot the screen, find the button, and click it. Kyra deliberately does not, and the reason is worth understanding because it shapes what you can safely allow.

Screen control can act. It cannot know what its action did. Did focus move? Did the save fail? Did the dialog that appeared mean success or an error? Every safety property has to be guessed from pixels — so an assistant driving this way will cheerfully announce success while the operation sits there failed, and there is no honest way for it to tell you otherwise.

A provider says what it means instead. Each action it offers declares:

What it changes — nothing, the view, a draft, saved data, the device, or something outside your machine entirely.
Whether it can be undone.
What it refers to — a real handle on a real thing, not “whatever is focused now”.

That gives you three things that matter:

Kyra knows whether it worked. An action is not reported as done until the application confirms it. And where an outcome genuinely cannot be observed — Kyra can start a call, but cannot hear whether it connected — the action says so, and Kyra tells you “started the call, can’t confirm it connected” rather than inventing either ending.

Stale references fail instead of acting. “This file” stops meaning anything when you close the file. A stale reference errors and Kyra re-resolves it, rather than acting confidently on the wrong thing.

Confirmation is derived, not guessed. Because actions declare their blast radius, your machine decides when to ask you — the application does not get to approve its own actions, and neither does a web page or a document that would very much like to. How much Kyra asks →

There is a fourth benefit that is easy to miss: deterministic beats generative. If your editor can rename a symbol properly, Kyra invokes that — it does not improvise forty edits and call it a rename.

Turning it off

Three levels, all instant:

To stop	Do
This session	Ctrl-C the `kyra connect`
This machine, from anywhere	Revoke it in Settings → Coding agents
Driving sessions in your editor	`kyra uninstall vscode`, then reopen them

Who can reach the door

Three layers, each answering a different question:

File permissions. The door lives in a directory only you can open. The strongest of the three — it makes access by another user impossible rather than detected afterwards.
The operating system names the caller. It tells the door which user is on the other end, unforgeably. Anything that is not you is dropped before a byte is read.
A per-run token. Not another answer to “which user” — anything running as you can read it. It defends against a stale door left over from a crashed run, and makes revocation trivial: restart, and everything reconnects or does not.

Why Windows needs WSL

The door refuses to open on native Windows. Run Kyra inside WSL and attach your editor to that WSL remote.

That is a decision, not an oversight. Two of the three layers above are missing on Windows, and both fail silently — the permission call reports success while setting no restriction at all, and Windows sockets carry no proof of which user connected. A door that reports itself secure while providing none of the protection is worse than no door.

Native support needs a genuinely different mechanism, which is why it is deferred rather than flagged off.