Local data
Every file LinkCode keeps on your machine, what each one is for, how credentials are protected, and how to reset it all for a clean slate.
Your host (the LinkCode daemon) keeps everything it owns under your home directory, in plain files you can inspect or delete yourself. Nothing here is synced anywhere unless you use a LinkCode Cloud feature that says so.
~/.linkcode/config.json
Optional — created the first time you save something that needs it. Holds listener overrides (host/port) and your per-agent settings: whether an agent is enabled, its default model, and which account it uses.
It holds no credentials. Those live in secrets.json below. Written with owner-only permissions (mode 0600). The environment variables LINKCODE_PORT and LINKCODE_HOST, if set, override whatever is in this file.
~/.linkcode/secrets.json
Every long-lived credential the host holds: API keys, the secret behind each provider account, your LinkCode Cloud sign-in, and the device key. The file is AES-256-GCM ciphertext, and the master key that opens it lives in your operating system's keyring — so a copy of the file alone tells an attacker nothing, and a backup restored onto another machine yields an empty credential store rather than a portable one.
Not every machine has a usable keyring
On a host with no usable keyring (a headless Linux box without a Secret Service, most often), the store degrades to plaintext rather than refusing to start, records that it did, and warns at boot. It re-encrypts itself as soon as a keyring appears. A plaintext store is portable — which is the same sentence as "readable by anything that can read the file."
Losing the keyring entry loses exactly the credentials and nothing else: the host reads as signed out, accounts drop out of the pool, and you re-enter what you need.
~/.linkcode/daemon.db
A SQLite database — the thread and workspace registry. It tracks which threads exist, which workspace each belongs to, when they were created and last used, and a pointer into the agent's own history so LinkCode can resume or import it.
It does not store your conversation content. The actual transcript lives wherever each agent keeps its own history. Migrations run automatically the first time a new host version starts.
~/.linkcode/runtime.json
Written once the host finishes binding its listener, with owner-only permissions. This is how a client finds a running host without you telling it a port: it reads this file for the host's process ID and URL, confirms that process is still alive, and confirms it actually answers as a LinkCode host before trusting it.
Removed automatically when the host shuts down cleanly. If the host is killed forcefully, a stale file can be left behind — the next start (or a client checking it) detects a dead process ID and ignores it.
~/.linkcode/cloud.json
Present once you sign in to LinkCode Cloud: which account and device this host is registered as. The credential itself is in secrets.json. Signing out removes both.
~/LinkCode
The folder backing Chats — the built-in workspace for threads that aren't tied to a project you added yourself. It's a normal folder: open it from the Chats section in the app, or browse it directly.
Downloaded agent runtimes
Agents LinkCode downloaded for you live in its asset store under the platform's application-data directory, alongside the desktop app's own data — for example ~/Library/Application Support/LinkCode/assets on macOS. Superseded versions are cleaned up automatically once a replacement lands.
Desktop settings and logs
The desktop app keeps its own settings — theme, language, appearance, and a manual host-URL override — as settings.json under its OS-standard per-app data directory, with owner-only permissions:
- macOS:
~/Library/Application Support/LinkCode - Windows:
%APPDATA%\LinkCode - Linux:
~/.config/LinkCode
The app also captures the host's output into a log file:
- macOS:
~/Library/Logs/LinkCode/main.log - Windows:
%APPDATA%\LinkCode\logs\main.log - Linux:
~/.config/LinkCode/logs/main.log
Ports
The host listens on port 19523 by default. If that port is taken by something else, it hunts upward — 19524, 19525, and so on, up to 19532 — before giving up. If the port is held by another host of the same install, the new process refuses to start instead: only one runs at a time. Clients don't need to guess which port won the hunt — they read it from runtime.json above. See troubleshooting if you hit a port conflict.
A LinkCode built from source keeps its own state directory (~/.linkcode.development) and its own port range, so it never collides with the installed app.
Resetting LinkCode
For a clean slate:
Quit LinkCode. The host shuts down with it.
Delete ~/.linkcode/daemon.db and ~/.linkcode/runtime.json. This clears your thread and workspace list. Nothing about your actual conversations is lost — each agent keeps its own transcripts independently of LinkCode, so anything resumable there survives and can be re-imported.
Delete ~/.linkcode/secrets.json (and config.json, cloud.json) too if you also want to clear saved accounts, API keys, and your Cloud sign-in.
Leave ~/LinkCode alone unless you actually want to delete your Chats files — it's a normal folder, not internal state.