Desktop app

The desktop application is the same Fosnie you use in a browser, connected to your own instance: the chats, projects and Libraries are the ones already there. Two things it can do that a browser tab cannot: it holds its connection outside the window, so a long answer survives a minimised window, a closed lid or a change of network instead of stopping mid-sentence, and it can work in a folder on your own computer.

It is available for Windows and macOS. To build it yourself instead, see Building the desktop client.

Pairing

Pairing uses a short code from your profile, so the app never asks for your password. Its credential belongs to that one computer, lives in the operating system's credential store, and can be withdrawn from the web at any time: your profile lists every paired device and revokes any of them.

The app can run against an instance it was not served by, which is the usual arrangement: one signed application, many instances, each with its own device token.

Connected folders

Connect a folder and a chat can work in it. The agent lists what is there, reads files, and, where you allow it, writes them, deletes them and runs commands.

• You choose the folder through your system's own picker, so nothing is reachable that you did not point at.
• You set how much an agent may do in it: read only, read and write, or read and write without deleting.
• Reading runs freely. Every write, command and deletion is shown to you first and copied aside, so a single file or a whole turn can be undone.
• A path that would leave the folder once links are followed is refused, and a command inherits none of the application's credentials.

Commands, and how often you are asked

On a computer where the agent's commands run inside an enforced boundary, that boundary already guarantees a command can only touch the connected folder and, unless it asks otherwise, cannot reach the network, so such commands run without interrupting you. You are still asked about a command that needs the internet, anything that would change files outside the folder, and every deletion. Where the boundary is not enforced the agent asks about every command, and an administrator can switch confirmation for every command back on for the whole deployment.

Scheduled tasks on your machine

A scheduled automation can be pointed at a connected folder on one of your machines: the schedule stays on the server, and the folder work is carried out by the machine itself. If the machine is offline when a run is due, the run is recorded as missed rather than skipped and can be made up once it reconnects. A step that changes a file waits for your approval, answerable from any device you are signed in to.

Seeing what the agent is doing

An agent's plan for a multi-step turn stays pinned above the conversation, collapsed to a single line you can open into the full checklist, ticking through one step at a time. When the turn finishes, a summary takes its place: the files it changed and the commands it ran, each with how it exited and the tail of its output. An actions-only toggle hides the prose so you can review a long turn by what it did rather than what it said.

A request for approval is hard to miss: decide it on one device and it settles everywhere you are signed in, the app carries a count of those waiting on its taskbar, and a task that fails in the background raises a notification.

Getting it, and keeping it current

The application arrives three ways: a signed download from us, an installer your own instance serves to its users, and a documented build from source. An installation that hosts its own copy never reaches us at all, because paired apps ask their instance for updates first, so a closed network stays current from inside itself and an administrator decides when the version moves.

Every installer is published with its SHA-256, so a vetting pipeline can confirm the file it received is the file that was published. Updates are signed and are applied only after you agree to them.