Support for different agents #90

New Issue

2026-05-28T01:43:07-04:00

didericis commented

2026-05-28 01:43:07 -04:00

I want to be able to use codex as well as any other agent harnesses I might want, and I want to be able to customize the agent container to have whatever extra I'd like. The actual agent files should still be provider/bottle agnostic, and be about purpose rather than security. Agent file = guidance. Bottle file = boundaries.

New features:

custom dockerfile to use for the agent environment (key in the manifest should something like "agent_provider")
bottle initialization supplies an "agent_template" option somewhere so I can say "this is a bottle for codex" or "this is a bottle for claude" and add the right default egress routes/roles

Things to change:

Claude code specific routes should not be automatically provided to the egress/those should be included explicitly in the bottle manifest
Roles/will need a new codex role for supplying auth

Things to look out for:

We don't want the user to be able to remove tools the agent needs to communicate with the supervisor, pipelock, egress, mcp, etc. In other words the baked in prepare/launch step should ensure the agent container has whatever dependencies it needs.

I want to be able to use codex as well as any other agent harnesses I might want, and I want to be able to customize the agent container to have whatever extra I'd like. The actual agent files should still be provider/bottle agnostic, and be about purpose rather than security. Agent file = guidance. Bottle file = boundaries. ## New features: - custom dockerfile to use for the agent environment (key in the manifest should something like "agent_provider") - bottle initialization supplies an "agent_template" option somewhere so I can say "this is a bottle for codex" or "this is a bottle for claude" and add the right default egress routes/roles ## Things to change: - Claude code specific routes should not be automatically provided to the egress/those should be included explicitly in the bottle manifest - Roles/will need a new codex role for supplying auth ## Things to look out for: - We don't want the user to be able to remove tools the agent needs to communicate with the supervisor, pipelock, egress, mcp, etc. In other words the baked in prepare/launch step should ensure the agent container has whatever dependencies it needs.

didericis added the Kind/Feature label 2026-05-28 01:43:07 -04:00

didericis-codex commented

2026-05-28 01:46:37 -04:00

This makes sense, but I would split it into two layers so agent guidance stays provider-agnostic:

Add a bottle-level agent_provider block, roughly { template: codex|claude|custom, dockerfile: <path>? }. Agents keep only purpose/guidance.
Move provider defaults into templates: default image/Dockerfile, launch argv, auth env placeholder behavior, and optional starter egress routes. The bottle still owns explicit egress; no hidden Claude routes.
Add provider roles: keep claude_code_oauth, add a Codex auth role, and make roles provider-scoped so validation can reject mismatches.
Preserve required infrastructure outside the user Dockerfile contract: launcher/prepare should still install or verify CA handling, supervisor MCP wiring, shell/git basics, and sidecar connectivity requirements. Custom Dockerfiles can add tools, not remove the minimum runtime contract.
Implement in small PRs: manifest schema + validation first, provider launch abstraction second, then Dockerfile customization and Codex template.

Main concern: avoid making agent_provider another security boundary surface. It should choose the harness/runtime; bottle egress, git, env, and supervise remain the boundary model.

This makes sense, but I would split it into two layers so agent guidance stays provider-agnostic: 1. Add a bottle-level `agent_provider` block, roughly `{ template: codex|claude|custom, dockerfile: <path>? }`. Agents keep only purpose/guidance. 2. Move provider defaults into templates: default image/Dockerfile, launch argv, auth env placeholder behavior, and optional starter egress routes. The bottle still owns explicit egress; no hidden Claude routes. 3. Add provider roles: keep `claude_code_oauth`, add a Codex auth role, and make roles provider-scoped so validation can reject mismatches. 4. Preserve required infrastructure outside the user Dockerfile contract: launcher/prepare should still install or verify CA handling, supervisor MCP wiring, shell/git basics, and sidecar connectivity requirements. Custom Dockerfiles can add tools, not remove the minimum runtime contract. 5. Implement in small PRs: manifest schema + validation first, provider launch abstraction second, then Dockerfile customization and Codex template. Main concern: avoid making `agent_provider` another security boundary surface. It should choose the harness/runtime; bottle `egress`, `git`, `env`, and `supervise` remain the boundary model.

didericis commented

2026-05-28 01:48:15 -04:00