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 Code | Codex | |
|---|---|---|
| Login | CLAUDE_CONFIG_DIR, kept between sessions | CODEX_HOME, kept between sessions |
| Skills | session-local plugin | folder inside the private configuration |
| Commands | session-local plugin | not delivered: Codex has no per-session prompts folder |
| Instructions | added to the system prompt | merged into CODEX_CONFIG |
| MCP servers | the daemon's gateway | the daemon's gateway |
| Settings fragments | merged, reserved keys stripped | merged, 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.