Codex App workspace separation은 개인 탐색과 리뷰의 위험을 낮추는 장치일 뿐, 서비스별 worker의 hard write boundary가 아니다. 공식 서비스 워커 안전성은 agent-runtime이 관리하는 worker profile, write allowlist, read/propose-only 분리, approval record, diff guard, 필요 시 sparse worktree와 container/read-only mount에서 나온다.

50 Codex App and Runtime Boundary 통합 지식 보고서

보고서 목록

확정된 원칙

• cwd나 Codex App workspace는 작업자의 기본 시야를 좁히지만 실제 쓰기 권한은 아니다.
• readAllow와 writeAllow를 분리하고, sibling service와 contracts/는 기본적으로 read-only 또는 propose-only로 둔다.
• Graphify는 navigation/context-router이고 RAG는 evidence retrieval cache다. 둘 다 SSOT나 write authorization source가 아니다.
• contracts/는 contract SSOT로 유지하고, contract 변경은 contracts agent 또는 root/e2e agent가 승인된 job에서 수행한다.
• 외부 변경 필요성은 몰래 수정하지 않고 structured handoff, proposal, approval request로 남긴다.

Sanctum 운영 모델

wallet-api는 넓게 읽되 wallet code, tests, context pack으로만 좁게 써야 한다. kms-api는 key management와 보안 경계가 관련되므로 write allowlist, diff guard, secret-like diff scanner를 우선 적용한다. hd-manager는 wallet, KMS, key lifecycle 사이에 있으므로 read scope는 충분히 제공하되 write scope는 서비스 내부로 제한한다.

mpc-manager-rs와 party-node-rs는 같은 Rust workspace 안에서 shared metadata, lockfile, protocol contract, e2e choreography 영향이 커질 수 있다. 각 worker는 자기 하위 서비스에 집중하고 상대 서비스 구현이나 workspace-level 파일 변경은 propose-only로 둔다.

실행 로드맵

1. Codex App workspace가 hard write boundary가 아니라는 boundary policy를 문서화한다.
2. 서비스별 cwd, readAllow, writeAllow, proposeOnly, handoffTargets, approvalPolicy를 worker profile registry로 정의한다.
3. 작업 전 baseline과 작업 후 changed files를 검사하는 diff guard를 먼저 도입한다.
4. service context pack을 정비하고, contracts.md는 canonical contracts/ mapping으로 작성한다.
5. 고위험 서비스에는 sparse worktree를 넘어 container/read-only mount와 writable service mount를 적용한다.

검증 질문

• 선택된 worker profile의 writeAllow가 실제 서비스 소유권과 일치하는가?
• readAllow가 필요한 contracts, dependency stubs, e2e role 문서를 충분히 포함하는가?
• 작업 전 dirty state와 작업 후 allowlist 밖 변경이 기록되었는가?
• Discord approval button은 approval_id만 포함하고 실제 scope는 서버에서 조회되는가?