plt-1261-codex-abc-eden-adoption-recommendation-2026-04-06

PLT-1261: Codex Cloud for ABC and Eden (EdenOS) — recommendation

Linear: PLT-1261
Date: 2026-04-06
Depends on (naming and secrets): PLT-1259, PLT-1260

Slack context: ABC and Eden are pilot (“guinea pig”) clients for controlled Codex adoption. Sandboxed workers and data-skills work (Awaish/Demi) are out of scope for this recommendation.

Linear workflow (as of 2026-04-06): Issue remains Triage (ops-Needs Grooming); assignee Sam.

Linear thread (accounted for)

Source	Intent	Reflected here
Issue comment (2026-04-03)	Spike depends on clarity from PLT-1260 and PLT-1259	Header Depends on + links to both briefs
Same comment	Next steps: confirm per-client use cases and isolation requirements, then propose env topology	Use cases to confirm below + Recommendation sections

Goal

Enable repeatable, safe Codex usage for delivery on ABC and Eden repos, with clear isolation (secrets, repos, data), onboarding, and a defined “good first use.”

Client repos (reference)

Client	Typical repo (local path)	Stack notes (high level)
ABC	clients/ABC/abchomeandcommercial	dbt, Rill, BigQuery — data/analytics delivery
Eden (EdenOS)	clients/Eden/eden-command-center	e.g. Mastra app — application delivery

Neither repo currently ships a .codex/ tree; adoption is greenfield at the repo level.

Use cases to confirm (Linear next step)

Fill with owners before pilot branches land (aligns with ticket scope: who runs Codex, which repos, which MCP/access).

Client	Who runs Codex (BF vs client)	Primary repo(s)	MCP / data access to allow	Isolation / compliance notes
ABC	TBD	abchomeandcommercial	TBD (e.g. GitHub, BigQuery — per engagement)	TBD
Eden (EdenOS)	TBD	eden-command-center	TBD (e.g. GitHub, app data stores)	TBD

Recommendation — environment topology

1. Same vs different Codex Cloud posture

Option	ABC	Eden	Rationale
Recommended for pilots	Dedicated Codex Cloud project (or workspace) or strict repo allowlist under one Brainforge-managed org	Same	Isolation: limits blast radius if MCP or prompt scope leaks; easier to explain to clients.
Alternative	Shared Brainforge default	Shared	Lower ops overhead; only acceptable if repo + MCP allowlists are enforced and secrets are not shared across clients.

Recommendation: Use parallel pilot configs: treat ABC and Eden as separate delivery contexts — either two Codex Cloud–visible scopes (if the product model supports it) or one org with two disconnected GitHub-linked projects and no shared secrets between them. Do not mix client data paths in one agent session.

2. Secrets and 1Password

• Brainforge AI Team vault holds Platform-wide keys (e.g. brainforge-openai-eastus2).
• Per-client vaults exist: Brainforge <> ABC Home and Commercial, Brainforge <> Eden.
• Recommendation: For client-operated or client-auditable trials, store client-specific Codex-related credentials (if any beyond shared Azure) in the client vault; Platform-wide BF operation continues to use team vault per PLT-1259 brief.
• Injection model: Prefer op-based runtime injection with a dedicated service account per client pilot. Do not rely on one shared Brainforge agent token or a developer desktop session for repeatable pilot access.
• 1Password Environments: If used for pilots, use them only as the named stage/client grouping (abc-dev, eden-dev, etc.). Keep the sensitive underlying credentials in vault items with scoped access.
• Tooling note: This gives us most of the operational benefit teams often seek from Doppler while staying inside the existing 1Password estate. If we later want stronger repo-level env typing for client apps, a Varlock-style layer could be added without changing the client-vault isolation model.

3. “Good first use” (concrete)

1. Add a minimal .codex/config.toml + .codex/README.md to one pilot branch per client repo, mirroring this monorepo’s .codex setup (Azure East US 2, Local Environment script appropriate to that repo’s package manager).
2. MCP allowlist: Only MCPs required for that client’s work (e.g. GitHub, no cross-client Supabase/Snowflake unless scoped).
3. Secrets bootstrap: Ensure the repo-level instructions use op run or the equivalent approved loader path, not a checked-in plaintext .env.
4. First task: “Read README and summarize module layout” — no production data writes.

Prerequisites (checklist)

• GitHub: Access to the client org/repo for the pilot branch.
• OpenAI / Codex: Decision on Brainforge-hosted Codex only vs client BYO org (open question in Linear) — record decision owner.
• Secrets: 1Password items identified per PLT-1259; no secrets in Linear.
• Automation identity: Dedicated client-pilot service account created and limited to only that client vault/project grouping.
• Compliance: Confirm client contract allows BF-operated AI on their repo; PII/data residency as applicable.
• Railway / deploy: Only if Codex is tied to a deployed env — align with Railway mapping in PLT-1259 (not required for repo-only Codex).

Next-step tickets (suggested)

1. ABC: Add .codex + README to abchomeandcommercial pilot branch; document MCP list + BF contact.
2. Eden: Same for eden-command-center (e.g. mastra-app root context).
3. Admin: Create or name Codex Cloud projects for pilot isolation (if separate projects chosen).
4. 1Password: Create dedicated client-pilot service accounts and confirm vault/project scoping.
5. PLT-1259/1260: Complete 1Password dedup + Codex Cloud org inventory appendices.

Out of scope (explicit)

• Sandboxed workers (separate initiative).
• Data-related skills roadmap (Awaish/Demi) — after env baseline.

Paste for Linear (comment)

PLT-1261 recommendation (topology for ABC + Eden pilots, prerequisites, next steps, links to PLT-1259/1260):
knowledge/engineering/environments/plt-1261-codex-abc-eden-adoption-recommendation-2026-04-06.md