Where data lives#

PacketBench writes to one hidden directory under your home folder, one platform log directory, the OS credential store, the webview's localStorage, and a handful of files inside your own projects. Nothing else. This page is the canonical list: every path, what owns it, and whether deleting it costs you anything.

It supersedes the four partial tables that used to live on Install & first run, Core concepts, Issues & git hosts and Architecture internals. Where those disagreed, the correction is recorded at the end of this page.

The data directory is the same on every platform#

There is no per-platform application-data folder. DATA_DIR_NAME is .packetbench (src-tauri/src/core/brand.rs:15) and it is joined onto the user's home directory, resolved from USERPROFILE and then HOME (src-tauri/src/core/shared.rs:16).

That means a Windows install puts application state in your user profile root, not in %APPDATA%. Only logs use a platform convention — see below.

One resolver can still adopt the pre-rename directory#

Most call sites join home/.packetbench directly. Four do not: the unified state file, the provider-settings file, PTY transcripts and the PTY pid registry resolve through core::storage::data_dir() (src-tauri/src/core/storage.rs:309), which returns ~/.packetbench when it exists and otherwise falls back to ~/.packetade — but only when that legacy directory classifies as Ours (src-tauri/src/core/migration.rs:82). The classifier exists because a sibling packetcode TUI claimed the older name after the rename, and writing our state into another product's home would scribble on someone else's data.

In normal operation the two resolvers agree, because startup migration creates ~/.packetbench before anything reads. They diverge only if the migration failed and a legacy Ours directory survives: state and transcripts would land in ~/.packetade while conversations and dictation land in ~/.packetbench. See Upgrades & migration.

Everything in the data directory#

Source order is by subsystem. "Safe to delete" means with the app closed, and describes what you lose.

known_hosts lives under ssh/, not at the root#

Two pages disagreed about this, and it matters: the wrong path sends you looking for a file that is not there when you are trying to work out why a host is unpinned.

The Rust source settles it. app_known_hosts_path() joins the data directory, then ssh, then known_hosts:

pub fn app_known_hosts_path() -> PathBuf {
    let home = home_dir().unwrap_or_else(|| ".".to_string());
    PathBuf::from(home)
        .join(crate::core::brand::DATA_DIR_NAME)
        .join("ssh")
        .join("known_hosts")
}

That is src-tauri/src/core/execution.rs:12-18, and it is the single definition — ensure_known_hosts_dir (line 22), the ssh_pin_host write path (src-tauri/src/commands/pty.rs:1381), the get_app_known_hosts_path command returned to the frontend (src-tauri/src/commands/pty.rs:1412) and the UserKnownHostsFile argument (src-tauri/src/core/execution.rs:113) all resolve through it. The true path is:

~/.packetbench/ssh/known_hosts

install.md placed it at ~/.packetbench/known_hosts. That was wrong. SSH remote workspaces and Settings were correct.

The bare name known_hosts does appear once outside that directory, in the migration marker list (src-tauri/src/core/migration.rs:30), where it is matched as a directory entry name to identify a pre-rename data directory. It is not a path.

Logs are the one platform-specific location#

Logs do not live in the data directory. dirs_log_dir() (src-tauri/src/lib.rs:40) uses the platform convention, under LOG_DIR_NAME = PacketBench (src-tauri/src/core/brand.rs:23).

The appender rotates daily, writing packetbench.log.<YYYY-MM-DD> (src-tauri/src/lib.rs:24). There is no retention limit and no pruning: the directory grows for as long as the app is used. Deleting old files is safe and is currently the only way to bound it. Old installs may also hold a PacketADE directory under the same parent (LEGACY_LOG_DIR_NAME, src-tauri/src/core/brand.rs:26); nothing reads it.

Three kinds of state, and how to tell them apart#

Conflating these is the most common source of confusion, because a setting you changed in the UI may live in any of the three.

The OS keyring holds every secret#

Service packetbench. API keys, git-host tokens, SSH passwords and the Packet Agent token, and nothing else. It is not a file, it is not in the data directory, and it is not included in a backup of your home folder. A keyring write failure is a hard error rather than a fallback to disk. The full entry table is on Security & credentials.

localStorage holds UI state and two authoritative slices#

The webview's localStorage, keys prefixed packetbench: (src/lib/brand.ts:28). It lives in the Tauri webview's profile directory, which is managed by the OS webview runtime — WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux — and is not a path PacketBench controls.

Most of it is presentational and losing it costs nothing: mosaic layouts, right-dock widths, sidebar preferences, the last-opened tab, onboarding dismissal, project history. Some of it is not:

On-disk state files hold everything durable#

The table above. state.v1.json is one PersistedState struct written through a two-tier lock so a stale full-state save cannot overwrite a slice save that landed in between — see Architecture internals.

Outside the data directory#

These are the paths PacketBench reads or writes that are not its own.

What is safe to delete#

Three useful resets, in increasing order of loss. Close the app first.

• Reclaim disk. Delete models/, pty-transcripts/, crashes/ and the log directory. Together these are almost all of the footprint; the models alone can be several gigabytes. Nothing durable is lost.
• Reset the UI without losing work. Clear the packetbench: keys in localStorage. Workspaces, flights and servers survive in state.v1.json; issues reload from the mirror; MCP trust profiles revert to defaults.
• Start over. Delete ~/.packetbench/ entirely. This also removes ssh/known_hosts, so every remote host reverts to unpinned and the next connection is trust-on-first-use. It does not clear the keyring — API keys, tokens and SSH passwords survive, and a re-created host record with a reused id will find its old password.

Where the four older tables were wrong#

Recorded rather than quietly fixed, so anyone holding a stale copy can tell which one they have.

Related#

• Security & credentials — what is in the keyring, and every trust boundary these paths sit behind.
• Install & first run — first launch, and the pre-rename migration that creates this directory.
• Upgrades & migration — what happens to ~/.packetade, and what those runs proved.
• Troubleshooting — symptoms that start with a missing or corrupt file here.
• Architecture internals — how state.v1.json is locked, recovered and quarantined.
• Memory — why project notes live in your repository rather than here.