Repository navigation
Keeping authority stable while the model switches #4579
Description
Area
CLI
What are you trying to accomplish?
Nice proxy. The combos and failover setup is the cleanest way I've seen to stop caring which provider is actually doing the work.
I've been working on the other half of that problem: what happens to the user's permissions and acceptance rules when the worker changes. I have a live Claude→Codex example where neither provider owns those rules — the worker changed mid-job, the approved job didn't restart, and the replacement didn't inherit the previous provider's authority or private context. The rules live with the owner and get checked at the receiver, outside either provider.
Two places where that maps onto what opencodex already does. First, the executor/policy boundary — your docs already disable native exec paths because they bypass the client's approval/sandbox path, which is exactly where receiver-owned authorization would sit. Second, cross-model subagents: one model can hand work to another while keeping the native UI, but delegating work shouldn't automatically delegate authority. The child should only carry what the user explicitly granted.
You made the model replaceable; I've been working on making the model's authority replaceable-independent too. Those two pieces fit unusually well. Write-up here if you want to look: https://github.com/terryncew/openline-wallet/blob/main/APPROVED_JOB_LIVE_001.md
What prevents this today?
Permissions and acceptance rules are provider-owned today: when the worker changes mid-job, the authorization context follows the provider instead of the owner.
What should OpenCodex do?
Keep the authorization rules with the owner and check them at the receiver, independent of which provider executes the work — so delegating work to a child model does not automatically delegate authority.
Example usage or interface
A Claude→Codex handoff mid-job where the replacement worker does not inherit the previous provider's authority or private context, while the approved job does not restart. Write-up: https://github.com/terryncew/openline-wallet/blob/main/APPROVED_JOB_LIVE_001.md
Alternatives or workarounds
No response
Additional context
No response
Checks
- I searched existing issues and documentation.
- This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
- I removed secrets and personal data.
Activity
lidge-jun commentedon Sep 14, 2026
리뷰 · 우선순위 32 / 80
지금
dev(HEAD000c0f1be, 방금 #4575 Devin rekey/Antigravity 진단 + #4577 Responses/media/history 팩이 들어간 직후)에서 OpenCodex가 이미 강하게 지키는 경계는 「실행 권한은 요청/설정 소유자에게 두고, 모델 텍스트로는 올리지 않는다」쪽입니다. Cursor native local exec는 기본 거부이고nativeLocalExec: "on"만 켠 설치만 통과합니다(structure/providers/cursor.md, ADR-0047/0048) — 프롬프트 안의 sandbox 마커는 진단용이지 허가가 아닙니다. Responses 경로의 undeclared-tool guard(src/server/responses-undeclared-tool-guard.ts)도 라우팅된 프로바이더가 요청에 선언되지 않은 클라이언트 툴을 내면 턴을 끊습니다. 서브에이전트는structure/subagents.md대로 모델 교체·폴백·동시성 한도는 있지만, 「부모가 승인받은 권한을 자식이 그대로 물려받는가」를 owner-scoped capability로 묶어 둔 계약은 아직 없습니다. 이슈 본문이 가리키는 Claude→Codex 중도 교체 예시는 바로 그 빈칸입니다. 모델(워커)은 이미 교체 가능하고, 승인/샌드박스/비공개 컨텍스트는 여전히 프로바이더·세션 쪽에 붙어 있어 워커가 바뀌면 같이 흔들리거나, 반대로 이전 워커의 권한이 새 워커로 새어 나갈 수 있다는 주장입니다. 링크된 openline-wallet APPROVED_JOB 쓰기와 방향은 맞지만, 현재 round 2/3 로드맵(#4573 레인·클로저 스윕, L2 풀 캐시 #4580/#4581, L4/L5 플랜) 안에는 「owner-owned authority plane」작업 항목이 없습니다. 버그 핫픽스가 아니라 설계·제품 경계 제안이라 오늘 당장 머지 트레인에 실을 우선순위는 낮습니다.이 이슈가 하려는 일은 두 문장으로 정리됩니다. (1) 승인된 잡의 권한·수용 규칙을 프로바이더가 아니라 owner/receiver에 두고, 워커(모델)가 mid-job으로 바뀌어도 그 규칙은 재시작·재위임 없이 그대로 검사되게 한다. (2) 크로스모델 서브에이전트에서 작업 위임과 권한 위임을 분리해, 자식은 사용자가 명시적으로 준 것만 들고 가게 한다. 이미 OpenCodex에 있는 「native exec는 클라이언트 approval/sandbox를 우회하니 기본 OFF」「undeclared tool은 실패」와 철학적으로는 잘 맞습니다. 다만 구현 표면이 아직 없습니다 — 어떤 객체가 job authority인지, 어디에 persist되는지, failover/account-pool 회전(#4546/#4580/#4581이 다루는 계정 바인딩)과 어떻게 직교하는지, Codex CLI approval 프롬프트·Desktop executor·MCP 각각에 어떻게 투영되는지가 본문에 없습니다. types.ts/config.ts 스플릿에 무효화될 PR도 아니고, 중복 이슈로 바로 닫을 만한 기존 티켓도 검색에서 안 보였습니다.
경로/심볼 -
structure/providers/cursor.mdCursor Native Exec / ADR-0047 — 「프롬프트 마커 ≠ 권한」은 이미 고정. 이 이슈의 receiver-check와 같은 가족이지만, Cursor 한 프로바이더 opt-in을 넘는 owner capability 버스는 아직 없음.경로/심볼 -
src/server/responses-undeclared-tool-guard.ts— 턴마다 선언 툴만 허용. 워커 교체 시 「이전 워커가 쓰던 툴 세트」를 새 워커가 자동 상속하지 못하게 막는 1차 방어는 여기 있음. job-scoped grant 목록은 없음.경로/심볼 -
structure/subagents.md/src/codex/subagent-model-fallback.ts— 모델 교체·폴백은 있어도 authority grant 전파 계약은 문서화되어 있지 않음. 자식이 부모 approval을 묵시 상속하는지가 미정이면 이 이슈의 핵심 공백.경로/심볼 -
src/codex/routing.ts계정 풀 재바인딩(#4580/#4581) — 워커/계정이 바뀌는 또 다른 축. owner authority가 계정 바인딩에 묶이면 캐시 친화 회전과 충돌하고, 안 묶이면 어디에 두는지 설계가 필요함.경로/심볼 - 외부 링크
terryncew/openline-walletAPPROVED_JOB — 참고 설계일 뿐 opencodex 트리 안 계약이 아님. 수용하려면 ADR + structure 문서 초안이 먼저.메인테이너의 판단이 필요한 지점
너의 추천
needs-design/enhancement로 두고 지금 구현 PR은 받지 말 것. 다음 스텝은 이슈에 짧은 설계 질문 체크리스트만 고정하면 됩니다 — (a) authority의 persist 키(스레드? 잡? Desktop session?), (b) 워커/계정 교체 시 재검사 시점, (c) 서브에이전트 grant의 명시 API, (d) native exec·undeclared-tool과의 관계. 그 ADR/structure/초안이 오기 전에는 help wanted로 두되, round 2/3 핫패스(#4580 캐시 가드, L4/L5)보다 앞에 두지 않는 것을 추천합니다.이 댓글은 grok-bot이 작성했습니다
terryncew commentedon Sep 14, 2026
The four design questions are useful. Here’s how I’d map this onto OpenCodex, separating the working demonstration from the proposed integration.
(a) Persistence. Keep the approved job and its rules under a stable job ID, independent of provider, account, or session. Bind each worker’s grant to that job separately. Changing workers should preserve the agreement without copying the previous worker’s credentials.
(b) Rechecking. Check the acting worker’s current grant before each gated action, including the first action after failover. A replacement needs its own valid grant. Revocation blocks subsequent gated actions; it does not establish that already-started effects have stopped.
(c) Subagents. I’d require an explicit child grant bounded by the owner’s approval. Assigning a task would not itself confer permission to execute it. The linked handoff demo doesn’t establish that contract for OpenCodex subagents.
(d) Existing guards. Keep native-exec restrictions, sandbox approvals, and undeclared-tool checks intact. The job grant would be an additional requirement at the existing execution check. It would never enable an execution path those controls prohibit.
The live Wallet demonstration shows Claude producing a checked checkpoint and Codex continuing from it under the unchanged agreement. Codex received repository state and a verified handoff, without Claude’s chat or credentials. The run stopped at Airlock eligibility; no production effect executed.
I’d start with one CLI execution path and document that contract first. OpenLine can serve as a reference without requiring an external runtime dependency.