Files

Paths here are defaults. Environment variables can move them. ~ is your home: the folder HOME names, or USERPROFILE on Windows.

​

The Pitboard directory

Pitboard’s directory is ~/.pitboard, or the path in PITBOARD_HOME. The command line and the app share it. On Windows, it is %USERPROFILE%\AppData\Local\Pitboard, whatever LOCALAPPDATA names. Pitboard creates each directory at mode 0700 and each file at 0600. On Windows, it gives each an access list that admits only you, SYSTEM and Administrators. A directory that already exists keeps its own. A copy in backups/ keeps the access of Claude Code’s config. Only vault/, signin/ and parks/ can hold a login. backups/ holds your email address, account ids and the path of each project Claude Code has opened. The status line writes usage.json and sessions.json without waiting for the disk, so after a power cut either can hold an earlier copy or nothing. Pitboard refuses a directory that a sync client copies to other machines, with state_on_synced_drive. It reads the path with links resolved: Your home’s own folders count, so /home/sync/.pitboard is refused.

​

Parked logins

On macOS, a keychain item’s account is the one Claude Code’s own item uses, from USER. Pitboard writes it through /usr/bin/security: on macOS 26, an item written through the Security framework takes about a second for each read by security, against 0.01 seconds. On Linux, a Secret Service item is labelled Pitboard parked login, with the attribute xdg:schema set to com.usepitboard.Pitboard.Park and service to its name. On KDE Plasma, KWallet answers for the Secret Service, and its default wallet is the default collection. There pitboard doctor and pitboard vault say KWallet in place of the login keyring. On Linux, state.json records how a Pitboard directory keeps its parked logins, as vault: Pitboard keeps the form a directory recorded until pitboard vault move changes it, and move records the form it names in a directory that recorded none yet. While a move is under way, vault also holds moving_to, the form it goes to, and once the new form is recorded, leaving, the parked logins still to be deleted from the form it left, with from and parks. When Pitboard renews Claude Code’s login, a copy of the renewed login waits beside the parked logins as pitboard-park-renewing-<time> until it is saved where Claude Code keeps it. <account id> is the id Pitboard gives the account at enrolment, which never changes: <time> is when the login was parked or last renewed, in milliseconds since 1 January 1970. Where parked logins are kept says who can read them.

​

Folders in parks

On macOS, each folder in ~/.pitboard/parks/ is a Claude Desktop parked login or a folder set aside. state.json records which folders are set aside. A folder set aside for an account stays until you forget that account or uninstall Pitboard. One that holds only what Claude made while signed out stays until pitboard uninstall. Each folder holds:

​

Claude Code files

Each place was read in Claude Code builds 2.1.278 to 2.1.309, and in 2.1.301 to 2.1.309 on Windows. With CLAUDE_CONFIG_DIR or CLAUDE_SECURESTORAGE_CONFIG_DIR set, the keychain or Credential Manager item’s name ends in - and the first 8 hex characters of the SHA-256 of that path as written. Pitboard waits about 7.5 seconds for a held Claude Code lock, then stops with switch_in_progress. As read in 2.1.309 and 2.1.284, Claude Code takes over a renewal lock after 60 untouched seconds and a write lock after 15.

​

Codex files

Each place was read in Codex 0.160.0, and in 0.164.0 on Windows. On Windows, Codex’s home is .codex in the profile folder Windows names for your account, whatever USERPROFILE says, as read in Codex 0.164.0. Pitboard switches Codex only while auth.json is its store, which cli_auth_credentials_store chooses. The Codex login store line of pitboard doctor names it. Each other store keeps the login elsewhere, as read in Codex 0.154.0 on macOS, in 0.165.0 on Linux and in 0.164.0 on Windows: On macOS, Pitboard does not read Codex’s keychain stores, because every read would ask you for permission. A login kept in memory leaves nothing to park. Codex reads cli_auth_credentials_store, and secret_auth_storage under [features], from these places, each over the one before:

1. Codex’s own default, file.
2. The system’s config.toml: /etc/codex/config.toml, or on Windows config.toml in %ProgramData%\OpenAI\Codex.
3. config.toml in ~/.codex or CODEX_HOME.
4. On macOS and Linux, /etc/codex/managed_config.toml.
5. On macOS, the managed preference config_toml_base64 of com.openai.codex, which a configuration profile sets.

The system’s requirements.toml, in /etc/codex or in %ProgramData%\OpenAI\Codex, then on macOS the managed preference requirements_toml_base64, pin the store over all of them. On Windows, as read in Codex 0.164.0, the policy RequirementsPath in HKLM\SOFTWARE\Policies\OpenAI\Codex names another file in place of that requirements.toml. The Codex login store line of pitboard doctor names the place that chose. Codex does not start while one of them is there and unreadable. Pitboard then refuses with live_store_unsupported. Pitboard reads a profile = "<name>" line as choosing the [profiles.<name>] table, which never sets the store. It refuses a line that names a profile no table defines. As read in Codex 0.164.0, four settings limit which ChatGPT logins Codex keeps. Codex reads forced_login_method and forced_chatgpt_workspace_id from the same places as the store, and allowed_login_methods and allowed_chatgpt_workspaces from the requirements that pin the store. As the interactive codex starts, it signs out of a login the first two rule out and deletes it. Every Codex leaves unused a login that any of the four rules out. Pitboard puts no such login in use, and refuses with login_restricted. The Codex login restrictions line of pitboard doctor names each setting and the accounts it rules out. Pitboard does not read three places Codex also reads:

• A trusted project’s .codex/config.toml, which can move the login while Codex runs there.
• A profile’s <name>.config.toml, read only with --profile, which codex login refuses.
• An enterprise’s cloud configuration, which codex login does not load. Whether a running Codex follows its store is not known.

​

Claude Desktop files

Pitboard reads these on macOS only. Claude’s data folder is ~/Library/Application Support/Claude. As read in Claude 2.7032.0, that ~ is your account’s own home, whatever HOME says. Where HOME names another folder, Pitboard leaves Claude Desktop alone. As measured in Claude 2.19675.0, eight items and three keys of config.json hold an account. Moving them moves it whole, both ways. As read in 2.42304.0, Claude clears more of the data folder when another account signs in, and Pitboard moves that with the account too. Pitboard moves them only while Claude is closed: the items by renaming, the keys by rewriting config.json. Any item may be missing. As read in 2.7032.0, claude-code-sessions and local-agent-mode-sessions keep each account’s sessions in a folder named for the account. Beside the data folder, Pitboard looks for Claude-3p/config.json. As read in 3.6556.2, it is there once Claude has run as a third-party deployment, and Claude runs from Claude-3p until deploymentMode in Claude-3p/claude_desktop_config.json names 1p. Pitboard reads that key, and moves no login while Claude-3p/config.json is there and the key does not name 1p. During a change, Pitboard holds an advisory lock on the data folder itself. It deletes nothing of Claude’s there. For pitboard doctor, it reads Claude’s build from /Applications/Claude.app. Pitboard reads the list of processes to tell whether Claude is open:

​

Renewal schedule

pitboard schedule install, or turning on Keep Saved Sign-Ins Fresh in the app’s Settings > Advanced, writes these. pitboard schedule uninstall, or turning it off, removes them. So do pitboard uninstall and the app’s Uninstall Pitboard while Pitboard’s directory is its default one. On Windows, uninstalling the app removes the task where it runs the app’s own pitboard.exe. On Linux, uninstall also has systemd forget when the timer last ran. status, uninstall and pitboard doctor look for the units in ~/.config/systemd/user too. <program> is the pitboard that installed the job, by the path it was started with, such as Homebrew’s link. From the app, it is the command line that came with it: Pitboard.app/Contents/Helpers/pitboard on macOS and bin\pitboard.exe in the app’s folder on Windows. The environment holds the proxy variables as they were set at install, and on macOS and Linux PITBOARD_NO_ARGV: see schedule. Each file is private to you, since a proxy’s address can hold a password. On Linux, systemd also hands the environment to programs that ask, as systemd.exec(5) says.

​

Watch service

pitboard watch install writes these, and pitboard watch uninstall removes them. So do pitboard uninstall and the app’s Uninstall Pitboard while Pitboard’s directory is its default one. On Windows, uninstalling the app removes the task where it runs the app’s own pitboard.exe. <program> and the environment are as for the renewal schedule.

​

The app

The apps keep these in app.json in Pitboard’s directory, so they follow PITBOARD_HOME:

​

Account windows

Account windows keep their data and records in your account’s own folders, apart from Pitboard’s directory, whatever the environment names. Website data has the rules. <id> is a version 5 UUID of claude: or codex: and the account’s id.