General Text & Computing Company

Agent Access

Let an AI agent (or any local script) read and edit your workspace files, safely and on your terms. It's a desktop-only, opt-in local bridge: off by default, bound to your own machine, and it only works while the app is running and unlocked.

Turn it on

Settings → Storage → Allow local agent access. That starts a small server bound to 127.0.0.1 (your machine only), mints a per-session token, and installs a tiny command-line tool at ~/.generaltext/gt.mjs. Turn it off anytime; the server stops and the token is discarded.

Use it yourself (a terminal)

The CLI reads the endpoint + token from ~/.generaltext/ automatically, so there's nothing to configure. Give yourself a short gt command with a one-line alias:

# add to ~/.zshrc (or ~/.bashrc) to keep it; or just paste it into your shell to try now
alias gt='node ~/.generaltext/gt.mjs'

gt workspaces                                   # see your workspaces
gt -w "My Workspace" list                       # files in one (by name or id)
gt -w "My Workspace" cat notes/todo.md
printf '%s' "# Hello" | gt -w "My Workspace" write hello.md

Want a permanent gt on your PATH (so any tool, not just your shell, can use it)? The installed script is executable, so symlink it into a bin directory:

ln -sf ~/.generaltext/gt.mjs /usr/local/bin/gt   # or ~/.local/bin/gt if that's on your PATH
gt workspaces

Point an agent at it

No setup on the agent's side. The tool runs with Node, which coding agents often already have. Copy the init prompt from the settings panel and paste it to your agent. It's written to have the agent verify the connection first, list your workspaces, and ask you which one to work in before it changes anything — so you stay in control of where it acts:

1. node ~/.generaltext/gt.mjs workspaces      → confirms it can connect + lists workspaces
2. the agent asks you which workspace to use
3. you pick; it passes -w "<that workspace>" on every command from then on

An agent's changes go through the exact same path as your own edits: encrypted, versioned, and synced to every device. (Prefer native tooling? The panel also shows a one-line command to register a Model Context Protocol server instead of the CLI.)

Choosing a workspace

An agent names the workspace it wants with -w (by name or id). You don't have to keep that workspace open: the app attaches to it in the background and keeps working it while you do other things, so a long-running task isn't interrupted when you switch around. An idle attachment is released on its own after a while.

What's protected

  • You opt in per machine, and it only runs while the app is open and your identity is unlocked.
  • Loopback + token. The bridge listens only on your own machine and requires the session token, so a web page or another user can't reach it.
  • App internals are off-limits. An agent can read and write your files, but can't alter an app's code or install records, only its data.
  • Everything syncs like a normal edit, so an agent's changes appear on your other devices and are captured in file history (so you can review or roll back).

A single file larger than the per-change sync limit is rejected with a clear message; split it into smaller files (agents do this well when asked).

Building an app with an agent

Agent Access can also drive the App Builder. Start a draft there, hand the prompt it gives you to your agent, and the agent registers its own dev server against that draft:

gt app preview my-draft http://localhost:5173

The Builder then shows your app running live, with its console output, while the agent keeps working — and you publish from the same screen when it's right. Because a draft is addressed by name, several agents can build different drafts at once; each shows up in the Builder's list with its own dev server.

Only loopback URLs are accepted (localhost / 127.0.0.1): a preview is something you're building on this machine, never a remote page. Drafts stay on the device they were made on, since a dev-server URL means nothing anywhere else.

For app makers

If you build General Text apps, document your app's data format in its README (see Publishing to the Gallery). The README travels with your app, so an agent working through Agent Access can read it and then read and write your app's data correctly, the same way a person would.