Maintenance commands

`renew`

Renew every parked login that is due, and nothing else

Usage: pitboard renew [OPTIONS]

A parked login is due when:

Tool	Due when
Claude Code	Its access token has expired or expires within 2 minutes, or its refresh token expires within 3 days.
Codex	Its access token has expired or expires within 2 minutes. Pitboard records no refresh token expiry for a Codex login.
Claude Desktop	Never. Pitboard renews no Claude Desktop login.

A parked login whose refresh token has expired is never due. Its account needs a sign-in again. pitboard status without --offline renews too, by the access token rule alone. renew asks Anthropic or OpenAI to renew each due parked login, with every request sent at once. renew never renews a login a tool is using. A parked login that copies one is dropped instead, since renewing it would spend the refresh token the tool holds. That account needs no sign-in.

Service answer	What happens	Logged outcome
Renewed	The renewed login replaces the parked one.	`renewed`
Refused	The parked login is dropped. Its account needs a sign-in again.	`parked_login_refused`
Unreachable, or asked for less traffic	Nothing changes. The next run tries again.	`renewal_deferred`
Another error	`renew` goes on with the other parked logins.	The error code

renew prints one line:

Output	When
`No parked login was due.`	Nothing was due.
`No parked login was due.`	Nothing was tried: another Pitboard run is changing something, a switch is interrupted or the account list cannot be read.
`2 due; none could be renewed this time.`	No due parked login was renewed.
`Renewed one.`	The only due parked login was renewed.
`Renewed all 2.`	Every due parked login was renewed.
`Renewed 1 of 2; the rest are tried again next time.`	Some due parked logins were renewed.

renew exits with status 0, even when nothing was renewed. Where Pitboard may change nothing, it fails with elevated or system_too_old.

pitboard renew

Renewed all 2.

`schedule`

Keep parked logins alive without running anything yourself

Usage: pitboard schedule [OPTIONS] <COMMAND>

Command	What it does	Output begins
`install`	Writes the job, replacing one already there, and hands it to the system’s scheduler.	`Parked logins will be renewed daily.`, then where the job is
`status`	Checks that the job is there, not whether it ran.	`Parked logins are renewed every 1d 0h by this computer's own scheduler.` or `Nothing is keeping parked logins alive here.`
`uninstall`	Stops the job and deletes what `install` wrote.	`Stopped renewing parked logins on a schedule.` or `There was nothing scheduled.`

The job runs pitboard renew once a day, from the pitboard that installed it, by full path. If that file is gone, pitboard doctor fails its schedule check: see Daily renewal stopped working. Renewal schedule lists its files. The job renews the parked logins in Pitboard’s own directory, ~/.pitboard or, on Windows, %USERPROFILE%\AppData\Local\Pitboard, whatever PITBOARD_HOME it is given. While PITBOARD_HOME names another directory, install refuses with schedule_not_default_home, and status says which directory the schedule renews. A link to the default directory counts as another directory. uninstall works whatever PITBOARD_HOME says. The system starts the job without your shell’s environment. install gives it each proxy variable it was started with: ALL_PROXY, HTTPS_PROXY, HTTP_PROXY and NO_PROXY, in either case. Run install again after your proxy changes. Until then, pitboard doctor warns with schedule_proxy. The app’s Keep Saved Sign-Ins Fresh setting gives the job the app’s variables, not your shell’s: see The schedule uses another proxy.

macOS
Windows
Linux

A LaunchAgent runs the job every 24 hours, the first time 24 hours after install. launchd skips a run due while the Mac sleeps. install writes the proxy variables and PITBOARD_NO_ARGV into the job.install refuses with schedule_refused when the program’s path or a variable holds a character a LaunchAgent cannot hold, and names it. It refuses with schedule_program_temporary when the program is in the temporary copy macOS makes of an app opened where it was downloaded.

A task in Task Scheduler, \Pitboard\Renew <SID>, runs the job each day at the time of day install ran, the first time a day later. It runs only while you are signed in to Windows, as you and not elevated, and stops after 10 minutes. Task Scheduler starts a run it missed as soon as it can.A task holds no environment, so install writes the proxy variables to schedule.env in Pitboard’s directory, and each run reads them from there. install refuses with schedule_program_temporary when the program is in the temporary copy Windows makes of a zip it opened.

A systemd user timer runs the job once each day, in the hour after midnight. Where the computer slept or was off through that hour, the job runs once it wakes or your user’s systemd starts. The job also runs at each sign-in to GNOME or KDE Plasma, once the session is up, so a run that found the login keyring locked catches up. systemd skips the job while its pitboard is not there. install writes the proxy variables and PITBOARD_NO_ARGV into the job.Before it writes anything, install asks your user’s systemd which folders it reads units from and which HOME it runs them with. It refuses with schedule_manager_elsewhere where systemd would not read systemd/user in XDG_CONFIG_HOME, or would run the job with another HOME. uninstall refuses with it too while systemd runs another HOME. Where nothing answers for your user’s systemd, as in a shell from su, uninstall asks systemctl all the same and takes the job away whatever it says.install refuses with schedule_refused when the program’s path holds a quote, a backslash or a control character, which no systemd unit runs. It refuses with schedule_program_temporary when the program is inside an AppImage, which runs from a folder that is gone once it quits.

On a Mac:

pitboard schedule install

Parked logins will be renewed daily.
/Users/me/Library/LaunchAgents/com.datlechin.pitboard.renew.plist

It renews your own parked logins and does nothing else: it never switches account and never asks Anthropic for usage.

On Windows, the second line is the task’s path, such as \Pitboard\Renew S-1-5-21-….

`vault`

Where parked logins are kept: in the login keychain

Usage: pitboard vault [OPTIONS] [COMMAND]

Command	What it does
`status`	Says where this Pitboard directory keeps the parked logins of Claude Code and Codex. The default.
`move <FORM>`	On Linux, moves every parked login into `secret-service`, your login keyring, or `files`, 0600 files in `~/.pitboard/vault`.

status reads Pitboard’s own files and, on Linux, asks your session’s bus whether a Secret Service answers, which can start your keyring there as any program’s first question to it does. It unlocks and changes nothing. Its first line says where they are:

First line	When
`Parked logins are kept in the login keychain, which every Pitboard directory on this Mac shares.`	macOS.
`Parked logins are kept in files in C:\Users\me\AppData\Local\Pitboard\vault, sealed to your Windows account.`	Windows.
`Parked logins are kept in the login keyring, which every Pitboard directory of your session shares.`	Linux, in the Secret Service.
`Parked logins are kept in 0600 files in ~/.pitboard/vault, which only you can read.`	Linux, in files.

Where KWallet answers for the Secret Service, as on KDE Plasma, vault and move say KWallet in place of the login keyring. On Linux, more lines follow, in this order:

Line	When
A move into the login keyring is under way: the next `pitboard status`, change or daily renewal finishes it.	A move was cut short.
`2 parked login(s) wait to be deleted from the login keyring: the next change deletes them.`	A move could not delete every parked login where they were.
`pitboard vault move files` keeps them in 0600 files in ~/.pitboard/vault instead.	In the Secret Service, with no move waiting.
`No Secret Service answers on this session's bus, so they cannot be read from here. Run Pitboard in your desktop session, where signing in unlocks the login keyring.`	In the Secret Service, where none answers.
A Secret Service answers on this session's bus: `pitboard vault move secret-service` keeps them in the login keyring instead.	In files, with no move waiting.
`No Secret Service answers on this session's bus, as over SSH or in a container.`	In files, where none answers.

Nothing moves parked logins between the two by itself. move asks both forms what they hold first, and where either is locked or nothing answers for it, it refuses with credential_store_locked and changes nothing. Then it records the move in state.json, writes each parked login into the new form and reads it back, records the new form, and only then deletes each from the old one. A move cut short is finished by the next change or renewal, before anything else writes a parked login: pitboard status renews first, and so does daily renewal, which refuses as for any parked login where the store refuses the move. A parked login another Pitboard directory keeps in your login keyring stays there.

Output	When
`Moved 2 parked login(s) into the login keyring.`	It moved them.
`Parked logins are kept in the login keyring from now on.`	There was none to move.
`Parked logins are already kept in the login keyring.`	They were there already. On a directory that recorded no form yet, `move` records this one.

A parked login it could not delete from the old form, as from a login keyring locked meanwhile, is said with parks_pending_removal and deleted by the next change. Another move deletes them first, and refuses while it cannot. On macOS and Windows, move refuses with vault_form_unsupported.

pitboard vault move secret-service

Moved 2 parked login(s) into the login keyring.

`log`

What Pitboard has changed, and when

Usage: pitboard log [OPTIONS]

Option	Description
`-n, --lines <LINES>`	How many changes to show. 20 by default.

pitboard log prints the most recent changes, oldest first. Each line gives the local time, a verb, the subject and the outcome. The outcome is ok, a code from the table, or the error code that stopped the change. With nothing logged, it prints Pitboard has not changed anything yet. Only --json says which front end made each change, in caller: cli, app, or unknown for older lines. The log is audit.log in Pitboard’s directory, and holds no email address. Past 256 KiB, Pitboard moves it to audit.log.1, replacing the one there, and pitboard log reads both.

Verb	Written when	Subject	Outcome
`use`	A switch you make, or Update Claude Code’s Config in the app.	The label	`ok`. `already_active` when the account was in use. `config_updated` when it was, and Pitboard wrote it into Claude Code’s config.
`auto-switch`	Pitboard switches Claude Code by itself, or such a switch fails.	The label switched to, or none if it failed before one was chosen	`ok`, or the error code
`auto-stay`	Pitboard could not identify whose login Claude Code has stored. One line per try.	The account last known in use, or none	`not_identified`
`auto-stay`	A limit of the account in use reached the share, and Pitboard held back. One line per limit and reset.	The account in use	A code from When it stays on the account
`in-use`	A read or a change finds the tool signed in outside Pitboard.	The account it finds signed in, or none if it is not enrolled	`signed_in_outside`
`in-use`	The same, for a sign-out outside Pitboard.	None	`signed_out_outside`
`in-use`	The same, for an account whose only login was replaced.	That account	`login_replaced`
`enroll`	An enrolment, with or without `--sign-in`.	The label	`ok`, or `label_unusable` when the label was refused
`park`	A Claude Desktop sign-in, from `pitboard enroll desktop/<label> --sign-in` or the app, starts to wait. It parks the account in use first, where there is one.	The label signed in to	`ok`, or the error code
`forget`	An account is forgotten.	The label	`ok`
`rename`	A label changes.	Before and after: `wrong -> right`	`ok`
`stow`	`pitboard stow`, or Clean Up in the app.	The account the file’s login was of, or none	What became of the login, as `stow` lists
`abandon`, `repair`	That command runs.	None	`ok`
`adopt`	`pitboard adopt` takes over a directory.	None	`ok`
`uninstall`	`pitboard uninstall` ran and Pitboard’s directory is still there.	None	`ok`, or `parks_pending_removal` when a parked login could not be deleted
`vault-move`	`pitboard vault move` ran.	The form: `secret_service` or `files`	`ok`, `already_kept` when they were there already, `parks_pending_removal` when one could not be deleted from the old form, or the error code
`renew`	`renew`, daily renewal, `status` or the app tries a due parked login.	The label	As the table in `renew` lists
`recover`	Pitboard finishes or undoes an interrupted switch before another change.	The label the switch was to	`interrupted_switch_finished` or `interrupted_switch_undone`
`reclaim`	A parked login is given back to its account.	The label	`ok`
`reclaim`	A parked login is discarded.	The parked login’s name, which holds an account id	`discarded`
`schedule`	Daily renewal is turned on or off, or the app repairs a schedule that ran the app itself or a `pitboard` that is gone.	`install`, `uninstall` or `repair`	`ok`
`watch-service`	The watch service is installed or taken away.	`install` or `uninstall`	`ok`
`warm-up`	A warm-up runs, by itself or with `warm now` or Warm Up Now.	The label	`ok`, or a code from Warm-up
`warm-on`, `warm-off`	An account is turned on or off for warm-ups.	The label	`ok`
`warm-range`	The hours warm-ups are made in change.	The hours: `07:00-23:00`	`ok`
`config`	Pitboard removes keys that name another account from Claude Code’s config.	The names of the keys	`dropped`

pitboard log -n 3

2026-09-22T09:14:03+07:00  enroll  personal  ok
2026-09-22T09:16:52+07:00  enroll  work  ok
2026-09-22T09:17:10+07:00  use     work  ok

`uninstall`

Delete every parked login this Pitboard wrote, the daily renewal schedule, the watch service and Pitboard's own files

Usage: pitboard uninstall [OPTIONS]

Option	Description
`-y, --yes`	Do not ask first; needed without a terminal or with `--json`.

While the Pitboard app is open, pitboard uninstall refuses with pitboard_open and deletes nothing: the app would make Pitboard’s directory again. Quit it with Quit Pitboard on macOS, or Exit in its icon’s menu on Windows. Otherwise it works in this order:

On macOS, where Pitboard holds a Claude Desktop login or a move of one waits, reads Claude’s data folder as a change does, and settles the move. If it refuses, nothing is deleted.
Stops and removes the watch service, then removes the daily renewal schedule. If either fails, it stops with nothing deleted.
Deletes every parked login this Pitboard wrote, and every folder set aside in ~/.pitboard/parks.
Deletes Pitboard’s directory, once every parked login and folder set aside is gone.

Step 1 stops with a code from Claude Desktop, such as app_open or uninstall_would_strand. The login each tool is using stays. On macOS, so do parked logins that pitboard repair gave back and this Pitboard did not write. The keychain is shared, so another Pitboard may own them. While a warm-up runs, step 4 keeps the directory. It also keeps it where a file in it could not be removed, and names that file. Run pitboard uninstall again once the warm-up is over or the file is closed. With PITBOARD_HOME set to another directory, it deletes that directory and leaves the schedule and the watch service. pitboard schedule uninstall and pitboard watch uninstall remove them. The question and the output name that directory. While CLAUDE_CODE_CUSTOM_OAUTH_URL is set, uninstall refuses with custom_oauth_endpoint. Custom OAuth endpoint says why. In a terminal, it asks first, as Questions before deleting describes:

Delete every parked login this Pitboard wrote, the daily renewal schedule, the watch service and ~/.pitboard? Each tool stays signed in to the account in use; the others need signing in again. [y/N]

Anywhere else, such as in a script or with --json, it needs --yes. Without it, uninstall refuses with confirmation_needed, exit status 2, and changes nothing. With two parked logins and daily renewal on:

pitboard uninstall --yes

Removed 2 parked login(s). The login each tool is signed in with is untouched.
Turned off the daily renewal schedule.
~/.pitboard is gone. Remove Pitboard itself the way you installed it.

Output	When
`Deleted 2 folder(s) set aside.`	On macOS, folders were set aside in `~/.pitboard/parks`. It follows the first line.
`Stopped the watch service.`	The watch service was installed. It comes before the schedule’s line.
Left 1 parked login(s) that `pitboard repair` found and this Pitboard did not write, because they may be another Pitboard's.	macOS only.
1 could not be deleted yet, so ~/.pitboard was kept; run `pitboard uninstall` again.	A parked login or a folder set aside could not be deleted, or a renewal of Claude Code’s login could not be saved yet. It takes the place of the last line.

On Windows, the question and the output name the directory by its path, such as C:\Users\me\AppData\Local\Pitboard. Remove Pitboard has the whole removal.

`doctor`

Check that what Pitboard relies on still holds on this machine

Usage: pitboard doctor [OPTIONS]

pitboard doctor prints one line per check: a mark, the check’s name and what it found. A line of advice follows where there is something to do. doctor changes nothing and sends no request.

Mark	`level` in JSON	Meaning
`✓`	`ok`	The check holds.
`!`	`warn`	Worth a look. Nothing is broken.
`✗`	`fail`	Something Pitboard relies on does not hold.

The last line sums up:

Last line	When
`Everything Pitboard checks is in order.`	Every check holds.
`One thing is worth looking at.`	One check warns and none fails.
`2 things are worth looking at.`	More than one check warns and none fails.
`1 broken: do not switch accounts until fixed.`	At least one check fails, and the number counts them.

doctor exits with status 3 when a check fails, and 0 otherwise. With --json, a failed check also sets ok to false and the error code to checks_failed. data still holds every check, as Data by command lists. --json writes your home folder as ~, and replaces each of these with a digest of its kind, such as <email 1a2b3c4d>:

Value	Kind
Email address	`email`
Your user name	`user`
Account id	`account`
Organisation id or name, Codex workspace id	`org`
Login fingerprint	`login`
Parked login name	`park`
A proxy’s host and port, when not on loopback	`proxy`
Your Windows account’s security identifier	`sid`

On Windows, --json also writes your profile folder as ~ and your local app data folder as %LOCALAPPDATA%, and finds your user name and security identifier in any case. Digests differ from one report to the next. Both reports write a proxy’s user name and password as ***. Otherwise the text report hides nothing. doctor prints its own checks and Claude Code’s first. Each other tool’s checks follow under a heading, in this order:

Heading	Shown when
`Codex`	Pitboard finds `codex`, Codex’s directory, `~/.codex` or `CODEX_HOME`, exists, or a Codex account is enrolled
`Claude Desktop`	A Claude Desktop account is enrolled, or a folder is set aside

When another tool’s checks appear and Claude Code is absent, doctor leaves out config_file, identity, in_use, slot, credential_size, credential_store, credential, fallback_login, storage_v5, claude_daemon, claude_version, status_line, auth_source and login_restrictions. Claude Code is absent when it has no config file, no claude program and no stored login, and no Claude Code account is enrolled. Some Codex levels depend on whether a Codex account is enrolled:

Finding	Codex account enrolled	None enrolled
Codex keeps its login outside `auth.json`	`fail`	`ok`
Pitboard cannot tell where Codex keeps its login	`fail`	`warn`
`auth.json` is absent	`warn`	`ok`
Codex is signed in some way other than a ChatGPT sign-in, such as an API key	`warn`	`ok`
The login in `auth.json` cannot be used	`fail`	`warn`

On macOS, Claude Desktop’s checks read the folders in ~/.pitboard/parks, open no cookie and list no process. Once a Claude Desktop account is enrolled, they also read Claude’s settings and the names at its data folder’s first level.

Every check

The checks in the order doctor prints them.

Code	Name	What it checks
`system_too_old`	`runs on`	Windows only, when it is older than Windows 11 24H2, build 26100, or Pitboard cannot tell its build. Always fails: see Pitboard changes nothing on this version of Windows.
`elevated`	`runs as`	Only where Pitboard may change nothing as it runs, or cannot tell whether it may. Always fails: see Pitboard changes nothing as root and Pitboard changes nothing as administrator. On Windows, it names User Account Control where that is off.
`homes`	`homes`	Only when a variable naming a home is empty or not a full path. Always fails, and nothing after it is checked.
`security_tool`	`security tool`	macOS only. `/usr/bin/security`, which reads the keychain, is there.
`config_file`	`config file`	Claude Code’s config file can be read. Warns where Claude Code has never run, and says to install it first where Pitboard finds no `claude`. Fails where the file cannot be read.
`identity`	`identity`	The account Claude Code’s config names. Warns when it names none.
`in_use`	`in use`	The account whose login Claude Code has stored, as Anthropic last named it. Warns when Anthropic has not been asked, or the config names another account.
`slot`	`slot`	Which of Claude Code’s login entries Pitboard reads. Always `ok`.
`credential_size`	`login size`	For a login in the macOS keychain: warns when it is too large for `security` to read from standard input, and fails then if `PITBOARD_NO_ARGV` is set. See Large logins on macOS. For a login in Credential Manager: how many pieces it takes, and fails when it is too large for any.
`no_argv`	`PITBOARD_NO_ARGV`	Windows only, while `PITBOARD_NO_ARGV` is set. Always warns: it changes nothing there.
`credential_store`	`credential store`	Where Claude Code keeps its login. On macOS, a file instead of the keychain warns. On Windows, Credential Manager in a profile that roams warns, and a Claude Code login in Credential Manager that nothing turns on fails.
`credential`	`credential`	The login’s shape and how long its refresh token has left, as a parked login’s. Warns under 3 days and once it has expired. Fails when the keychain is locked and cannot ask for its password, when Credential Manager cannot be reached, or when its pieces cannot be joined.
`fallback_login`	`fallback login`	macOS and Windows, when a login file sits behind the keychain or Credential Manager. Always warns. See Claude Code over SSH uses another account.
`home`	`Pitboard home`	Only you can read Pitboard’s directory. Warns otherwise.
`private_on_disk`	`logins on disk`	No file that holds a login can be read by other users: Claude Code’s login file and, on Linux and Windows, the parked logins. Fails otherwise, with the `chmod` or `icacls` commands that fix it.
`vault`	`parked logins`	On Windows, the parked logins are sealed to this Windows account. Fails when none of them opens, and names a `pitboard enroll <label> --sign-in` for each.
`vault`	`parked logins`	On Linux, where the parked logins are kept: `ok` in the login keyring, and in files where no Secret Service answers on your session’s bus. Warns in files where one answers, and names `pitboard vault move secret-service`. Warns while the login keyring is locked or nothing answers for it, while a move is under way, and while parked logins a move left wait to be deleted.
`state`	`accounts`	The account list can be read, and how many accounts are enrolled.
`parked_login`	`account <label>`	One per Claude Code account. Warns when nothing is parked to switch to, the parked login is expired or due, or the keychain is locked. Fails when it cannot be used.
`interrupted_switch`	`interrupted switch`	Only when a switch did not finish. Always warns. Suggests `pitboard abandon` when the next change cannot finish it.
`discarded`	`old parked logins`	Only when parked logins are waiting to be deleted. Always warns.
`machine_id`	`machine id`	Warns when this machine has no stable identifier. On Windows, it is always there, `ok`, and says that a copy of the PC, such as a whole virtual machine, takes this PC’s accounts for its own.
`local_app_data`	`local app data`	Windows only, when Windows keeps your local app data somewhere other than `AppData\Local` in the folder `USERPROFILE` names. Always warns: Pitboard keeps its directory there whatever Windows says.
`roaming_profile`	`roaming profile`	Windows only, when your profile roams. Always warns: Claude Code’s and Codex’s logins go to every PC you sign in to.
`wsl`	`WSL`	On Windows, the WSL distributions there, whose Claude Code and Codex Pitboard on Windows does not switch. It adds that a switch on Windows changes the login of a Codex there that uses the Windows Codex home. Inside WSL, says Pitboard there switches what is installed in that Linux, and Pitboard for Windows the Claude Code and Codex installed on Windows, which keep their own logins. Where Codex’s home is on a Windows drive, it says that only of Claude Code. It adds that Codex starts no shared background server there, as read in Codex 0.163.0, and that a switch there changes the login of Codex on Windows where it uses the same folder. Always `ok`.
`pitboard_copies`	`copies of pitboard`	Windows only, when more than one `pitboard` is on your `PATH`. Names the one a shell runs. Always `ok`.
`system_proxy`	`Windows proxy`	Windows only, when Windows’ proxy settings name a proxy and `HTTPS_PROXY` is not set. Says where Codex, Claude Code and Pitboard send their requests. Always `ok`.
`storage_v5`	`storage v5`	Claude Code’s storage v5 flag. Warns when it is on and the login is in a file.
`claude_daemon`	`Claude Code daemon`	Whether Claude Code’s daemon has run here, and whether it runs. Always `ok`.
`pending_parks`	`parks being reclaimed`	Parked logins Pitboard started to write and has not accounted for. Warns when one cannot be read.
`schedule`	`renewal schedule`	Only when daily renewal is on for Pitboard’s own directory. Fails when the program it runs is gone or is the app itself. Warns when it does not name a program, and when a run of it could not open the parked logins, such as in a locked keychain or login keyring, until a run of it opens them. On Windows, warns when a setting of the task changed in Task Scheduler or its last run failed.
`watch_service`	`watch service`	Only when the watch service is installed for Pitboard’s own directory. Fails when the program it runs is gone. Warns when it does not name a program, and when a switch or warm-up of it could not open the parked logins, until one of them opens them. On Windows, warns when its last run failed.
`schedule_proxy`	`renewal schedule's proxy`	Only when the job’s requests would go another way than this run’s. Warns, but is `ok` in the app. See The schedule uses another proxy.
`claude_version`	`Claude Code build`	The installed Claude Code version, and the build of it for this system that Pitboard’s facts were read from. Always `ok`.
`status_line`	`status line`	Windows only. The shell Claude Code runs its status line in, Git Bash, PowerShell 7 or Windows PowerShell, and the `pitboard` it finds there. Warns when Claude Code’s status line runs `pitboard` and that shell finds none.
`auth_source`	`what a session authenticates with`	Warns when Claude Code uses something other than its stored login, such as `ANTHROPIC_API_KEY` or `apiKeyHelper`.
`login_restrictions`	`login restrictions`	Only when managed settings set `forceLoginOrgUUID`, or `forceLoginMethod` to `console`. Names each and where it is set. Warns when `forceLoginOrgUUID` leaves out an enrolled account’s organisation, which Pitboard then does not put in use.
`asking`	`asking Anthropic`	Warns while Pitboard waits to ask about usage, after a service asked for less traffic or could not be reached. The name lists the services asked.
`network`	`network`	Direct, or which proxy and which variable named it. Warns for a variable holding no proxy address Pitboard can read. Warns for a SOCKS proxy, which Pitboard does not use, where `NO_PROXY` leaves a host it calls.
`dormant_account`	`account <label>`	Only for a Claude Code account not switched to for 30 days or more. An account enrolled with `--sign-in` and never switched to gets none. Always warns.
`codex_installer_home`	`Codex's home`	Windows only, when `CODEX_HOME` is not set and your profile folder is not the one `USERPROFILE` names: Codex then keeps its login in one `.codex` and its installer uses another. Always warns.
`codex_backend`	`Codex login store`	Where Codex keeps its login. Pitboard switches only the file store, `auth.json`.
`codex_login_restrictions`	`Codex login restrictions`	Only when a setting limits which ChatGPT logins Codex keeps, such as `forced_chatgpt_workspace_id`. Names each setting and where it is set. Warns when it rules out an enrolled account, which Pitboard then does not put in use. Fails when Codex cannot read one.
`codex_auth_file`	`Codex login file`	File store only. `auth.json` exists, and only you can read it.
`codex_login`	`Codex login`	File store only. The login in `auth.json` is a ChatGPT sign-in Pitboard can read.
`codex_credential_manager`	`Codex in Credential Manager`	Windows only, file store only, when Credential Manager holds Codex’s `cli\|` or `secrets\|` items. Counts them. Always `ok`.
`codex_parked_login`	`account codex/<label>`	As `parked_login`, for each Codex account.
`codex_dormant_account`	`account codex/<label>`	As `dormant_account`, for each Codex account.
`codex_version`	`Codex build`	As `claude_version`, for Codex.
`codex_running`	`running Codex`	What runs `codex` as you, by kind, with process IDs. Its advice says how each takes a switch. Always `ok`.
`desktop_data_folder`	`Claude data folder`	Claude’s data folder. Warns when it does not exist yet. Fails when Pitboard leaves Claude Desktop alone, as with `HOME` set to another folder. Fails when it is a link, Claude runs from `Claude-3p` beside it, or Reset App Data waits in it. On Windows and Linux, it is the only Claude Desktop check, always `ok`, and names the Claude Desktop accounts an index brought from a Mac holds.
`desktop_settings`	`Claude settings`	`config.json`, and a `config.json.journal` beside it, can be read. Fails otherwise.
`desktop_layout`	`Claude data folder layout`	Each part of the account’s data in the data folder is one Pitboard moves. Warns otherwise: Pitboard starts no Claude Desktop move while one is there.
`desktop_login`	`Claude Desktop in use`	The account Pitboard last read in use, and when. Warns when Pitboard has read none, Claude’s settings cannot be read, they have named another account since, Claude looks signed out, or that account also holds a parked login.
`desktop_parked_login`	`account desktop/<label>`	One per Claude Desktop account. Warns when nothing is parked to switch to, its sign-in may have lapsed, or `parks/` could not be looked at. Fails when its folder is missing from `parks/`.
`desktop_move`	`interrupted Claude Desktop move`	Only while a move waits. Always warns.
`desktop_awaiting`	`awaited sign-in`	Only while Claude is signed out for a sign-in, with an account parked for it. Always warns.
`desktop_parks_folder`	`parked Claude Desktop logins`	Only when `parks/` exists. Only you can open it, and it is on the data folder’s volume. Fails otherwise.
`desktop_set_aside`	`folders set aside`	Only when folders are set aside. How many, which hold a login, and whose parts of a login the others hold. Warns when one holds a login that no account in use or parked keeps beside it.
`desktop_build`	`Claude`	The installed Claude’s version, and the builds Pitboard’s facts were read from. Always `ok`.

Get started

Install and remove

Use Pitboard

Troubleshooting

How it works

Reference

Maintenance commands

`renew`

`schedule`

`vault`

`log`

`uninstall`

`doctor`

​renew

​schedule

​vault

​log

​uninstall

​doctor

`renew`

`schedule`

`vault`

`log`

`uninstall`

`doctor`