PogCode Open the app
Contents

Agents

A named setup you reuse: the harness, the model, the instructions and the permissions. One definition reaches Claude Code and Codex alike, in the form each understands.

You pick an Agent when you start a Thread, add one to a Thread already running, or set what a Project starts with. The definition lives in your account, so the same Agent behaves the same way on every Computer that can run it.

A harness is the program that runs an agent: Claude Code or Codex. PogCode treats them as interchangeable workers. Nothing you configure is written into their dotfiles, and a running session never reads whatever else is on the machine.

Which harnesses

Claude Code and Codex are supported today. Each is installed and pinned to a version per Computer, and a conformance suite must pass at that version before it is offered: isolation of the private configuration, identity settings, a clean PATH, honest reporting of what was delivered, protection of reserved keys, and a live session inside the rendered configuration.

Instructions and commands

Instructions are rules an agent follows; Commands are prompts you reuse. Both are plain text, written once for the account, and reach every Computer. Instructions reach Claude Code as an addition to its system prompt and Codex through its CODEX_CONFIG environment. Commands reach Claude Code as a session-local plugin; Codex has no per-session prompts folder, so Commands are reported as not delivered there, in the Agent editor, before you run anything.

The harness's own settings

Each harness has settings PogCode does not model one by one: compaction thresholds, reasoning effort, sub-agent tuning and whatever comes next. A settings fragment is a JSON object for exactly one harness, passed through as it is. The daemon does not interpret it, except to strip the keys that harness reserves and tell you it did, so a fragment cannot redirect credentials, silence the permission flow, register its own MCP servers or run commands. A fragment for a harness this Computer does not know is kept untouched and skipped, never treated as an error.

How each setting reaches each harness

Your configuration is stored once, in a form that belongs to no harness. The daemon translates it into what each harness understands. When a harness cannot carry something, the Agent editor says so before you run anything.

Claude CodeCodex
LoginCLAUDE_CONFIG_DIR, kept between sessionsCODEX_HOME, kept between sessions
Skillssession-local pluginfolder inside the private configuration
Commandssession-local pluginnot delivered: Codex has no per-session prompts folder
Instructionsadded to the system promptmerged into CODEX_CONFIG
MCP serversthe daemon's gatewaythe daemon's gateway
Settings fragmentsmerged, reserved keys strippedmerged, reserved keys stripped

The one thing that outlives a session is the harness's own login, so signing in to Claude Code or Codex once serves every Project on that Computer.

A private configuration per session

What a session gets is the Project's defaults, plus the Thread's overrides, plus whatever the Agent itself requires. That selection is fingerprinted and pinned when the session starts, so it cannot drift while it runs, and two sessions with different selections never share a harness process. The private configuration is its own HOME, a short allowlist of environment variables, and a PATH without mutable tool shims. It is built when the session starts and thrown away when it ends.