Configuration#

PacketBench keeps ordinary preferences in its application state and secrets in the operating-system credential store. Prefer the Settings interface over environment overrides.

Before you start#

• PacketBench opens successfully.
• You know which provider, shell and git host you intend to use.
• API keys have the minimum scopes required by their provider.

Configure a model provider#

1. Open Settings → Agents & Models.
2. Select Anthropic, OpenAI, MiniMax, OpenRouter, Ollama or a custom compatible endpoint.
3. Save the API key when the provider requires one.
4. For MiniMax or a custom compatible endpoint, give an https:// base URL.
5. For Ollama, verify the base URL before saving it.
6. Refresh models and choose a default only after discovery succeeds.

PacketBench refuses a plain http:// base URL for MiniMax and for a custom compatible endpoint, because the API key is sent on every request. Plain http:// is accepted only when the host is local: a loopback address, localhost, a private-network, link-local or unique-local address, a single-label hostname, or a name ending .local, .lan, .internal, .home.arpa or .localhost. Ollama carries no key and is not restricted.

PacketBench exposes separate rows for the Anthropic SDK and Anthropic API, and for the OpenAI API and OpenAI Agents SDK. They share their vendor API key but use different runtimes. Subscription credentials are not used for API-agent rows.

Configure terminals and coding CLIs#

Under Workspaces & Terminal, choose the default local shell and inspect the detected CLI clients. PacketBench can open ordinary shells and installed coding CLIs. A missing client must be installed or pointed at an executable before a workspace pane can launch it.

Configure project rules#

Use the Project Rules editor to review the instructions applied to coding agents in the current project. Save only rules you intend to place in the project files; do not paste secrets into them.

Trust a project for repository-supplied automation#

Three files inside a repository can make PacketBench run code the repository supplies:

None of them load unless you have listed that project as trusted. An untrusted project is skipped and the skip is recorded in the application log, so a hook or project MCP server that never starts is diagnosable.

To trust a project:

1. Create or edit trusted-projects.json in your PacketBench data directory (~/.packetbench on Linux and macOS, %USERPROFILE%\.packetbench on Windows).

2. List the absolute path of each project you trust, in the form your platform uses. Windows separators are escaped because the file is JSON:

   Copy

   {
     "version": 1,
     "projects": [
       "C:\\Users\\you\\projects\\your-app",
       "/home/you/projects/another-app"
     ]
   }

3. Start a new conversation in that project. The list is read each time PacketBench makes the decision, so no restart is required.

Warning: adding a project lets that repository run shell commands and spawn processes as your user. Trust a repository only when you would run its scripts yourself, and re-check it after pulling changes from an untrusted contributor.

Entries must be absolute paths. Relative or blank entries are ignored, trust is never inherited by a repository nested inside a trusted one, and a file that is missing, unreadable, invalid JSON or not "version": 1 trusts nothing at all. There is no environment variable that overrides this list.

Verify#

• Provider status is ready and model refresh returns at least one usable model.
• A new Terminal pane launches the chosen shell.
• A read-only agent turn completes in the intended project.
• Repository hooks and .mcp.json servers run in a trusted project and are absent in an untrusted one.
• After restarting PacketBench, preferences return and API keys are not shown in plaintext.

Environment variables such as provider endpoint overrides and developer sidecar paths are intended for controlled deployments and debugging. Remove an override when troubleshooting so the saved Settings value can take effect.