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).
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.