OpenCode 2에서 부모 에이전트의 설정에 넣은 편집 금지는 하위 에이전트의 설정으로 자동 전달되지 않습니다. 다만 세션 자체에 부여한 권한 규칙은 자식 세션을 만들 때 이어받습니다. 작은 팀이 검토 작업을 나눠 맡기려면 먼저 제한을 에이전트 정의에 넣었는지, 세션에 넣었는지 구분해야 합니다. 이 글은 같은 파일의 edit 요청을 따라 두 경우와 공통 정책의 차이를 설명합니다.
확인: 2026년 10월 17일 00:33–00:38 UTC. 검토 대상: npm @opencode/cli의 당시 latest 버전 2.0.32와 해당 태그의 커밋 843a6c5. 공식 문서·공개 소스·상위 프로젝트의 테스트 코드를 읽었으며 OpenCode 설치, 실행, 모델 호출은 하지 않았습니다. 아래 결과는 가정한 설정에 대한 소스상 예상 판단이며 실행 결과가 아닙니다.
새 프로젝트가 아니라, 작업을 나누는 방식이 바뀐 기존 도구
Anomaly의 OpenCode는 모델을 연결해 코드를 읽고 수정하며 도구를 사용하는 오픈소스 코딩 에이전트입니다. 저장소 생성일은 2025년 4월 30일입니다. 2.0 소개에서 강조한 변화 중 하나는 부모가 작업을 계속하는 동안 하위 에이전트를 백그라운드로 실행하는 기능입니다. 기존 1.x의 플러그인과 서버 API를 그대로 사용할 수 있는 업그레이드는 아닙니다.
현재 관심과 최초 공개일도 나눠 봐야 합니다. 공식 npm 기록에서 2.0.0은 9월 11일, 검토한 2.0.32는 10월 16일 22:14 UTC에 올라왔습니다. 10월 14일 등록된 Hacker News의 2.0 토론은 확인 시 878점·댓글 384개였습니다. GitHub 별은 00:32 UTC에 누적 214,354개였고, Trendshift 날짜별 집계에는 10월 14일 +281개, 15일 +390개가 기록돼 있습니다. 00:37 UTC에 확인한 날짜별 집계이며, 구간의 시간대 경계는 확인하지 못했으므로 최근 24시간 증가량으로 바꾸어 읽지 않았습니다. 이는 관심의 단서이며 성능이나 운영 안정성의 증거는 아닙니다.
검토 버전의 라이선스는 MIT입니다. npm 패키지는 macOS·Linux·Windows와 arm64·x64 대상을 선언하지만, 여기서 각 환경의 실행 여부를 검증하지는 않았습니다. 설치 경로와 1.x 플러그인·서버 연동의 이전은 V2 마이그레이션 문서를 기준으로 확인해야 합니다.
편집 금지를 어디에 넣었는가
가상의 부모 에이전트를 coordinator, 하위 에이전트를 reviewer라고 하겠습니다. 둘 다 이 사례를 위해 붙인 이름입니다. 부모는 검토를 맡길 수 있지만 직접 편집하지 못하게 하고, 하위 에이전트에는 기존의 edit: allow 설정이 남아 있는 상황입니다. 하위 에이전트가 프로젝트 안의 가상 파일 demo/report.md를 편집하려 할 때를 보겠습니다.
여기서 세 가지 저장 위치는 서로 다릅니다.
agents.coordinator.permissions: 부모 역할의 규칙입니다.- 설정 파일 최상위의
permissions: 여러 에이전트에 먼저 적용하는 공통 규칙입니다. 개별 에이전트 규칙이 뒤에 붙습니다. session.permissions: 세션 생성 API 등으로 특정 세션에 부여하는 규칙입니다. 설정 파일의 최상위permissions와 같은 것을 가리키지 않습니다.
에이전트 설정을 합치는 소스는 공통 규칙을 붙인 뒤 각 에이전트의 규칙을 붙입니다. 마지막으로 일치하는 규칙이 판단을 정하므로, 공통 금지를 추가했더라도 하위 역할에 남은 허용이 다시 이길 수 있습니다.
위임과 편집은 서로 다른 단계에서 판단합니다
- 부모가 하위 에이전트를 부를 수 있는지 검사합니다.
subagent도구는 부모 세션과 호출한 에이전트의 권한으로 대상reviewer호출을 검사합니다. 이 검사를 통과했다는 사실만으로 하위 작업의 편집까지 허용되거나 금지되는 것은 아닙니다. - 선택한 하위 역할로 자식 세션을 만듭니다. 생성 요청에는
reviewer라는 에이전트가 들어갑니다. 부모 역할의 에이전트별 규칙을 복사하는 요청은 없습니다. 반면 공통 세션 생성 함수는 별도 권한 입력이 없으면 부모의session.permissions를 자식에게 넣습니다. - 하위 에이전트가 편집을 시도할 때 다시 검사합니다. 자식에게 선택된 에이전트의 규칙 뒤에 자식 세션의 규칙을 붙여 판단합니다. 그 결과가 거부가 아니라면 저장된 승인과 정책 검사도 이어집니다.
이 흐름은 위임 도구, 자식 세션 생성, 권한 평가를 연결해 읽은 것입니다. 따라서 “부모 권한은 전혀 상속되지 않는다”라고 요약하면 세션 수준의 상속을 놓칩니다.
같은 파일 요청, 제한 위치에 따른 네 가지 결과
아래는 각 행을 따로 적용한 비교입니다. 부모의 위임은 허용됐고 대상 에이전트도 유효하다고 가정합니다. 하위 역할에는 edit: allow가 있으며, 표에 적지 않은 세션 규칙·저장된 승인·추가 정책·사용자 플러그인의 개입은 없는 조건입니다. 각 금지는 모든 파일을 뜻하는 *에 적용합니다.
| 거부 규칙의 위치 | 하위 에이전트의 edit 검사 예상 |
|---|---|
| 부모 역할의 permissions에만 edit 거부 | 허용. 자식은 부모 역할 대신 자신의 역할 규칙을 사용합니다. |
| 설정 최상위 permissions에 edit 거부 | 허용. 뒤에 붙는 하위 역할의 edit 허용이 이 조건에서는 우선합니다. |
| 부모 session.permissions에 edit 거부 | 거부. 자식 생성 시 이어받은 세션 규칙이 하위 역할 규칙 뒤에서 적용됩니다. |
| 공통 policies에서 tool.use의 edit:* 거부 | 거부. 일반 권한이 허용이어도 정책 검사가 막습니다. 더 높은 권한의 정책이 이를 해제하지 않는 조건입니다. |
세 번째 행의 상속은 자식 생성 시점의 처리입니다. 상위 프로젝트에도 부모 세션 규칙의 상속과 명시적 빈 배열에 의한 대체를 확인하는 테스트가 있습니다. 이 테스트는 읽기만 했으며 직접 실행하지 않았습니다. 부모 규칙을 나중에 바꿨을 때 기존 자식까지 갱신된다는 뜻으로 확대하지 않았습니다.
네 번째 행에서 policies는 일반 권한을 거부로 좁히는 추가 검사입니다. 정책의 allow 예외도 도구 실행을 새로 승인하지는 않습니다. 예외가 앞선 정책 거부를 해제하더라도, 저장된 승인 등을 거쳐 정책 검사에 들어온 판단이 ask라면 승인 요청이 남습니다. 정책 훅 구현과 상위 프로젝트의 정책 테스트가 이 차이를 보여 줍니다.
작은 팀에서 정할 일
검토 역할 하나의 동작을 바꾸려면 그 하위 에이전트의 규칙을 먼저 고치는 편이 직접적입니다. 부모에만 편집 금지를 넣고 검토 프롬프트를 넘기는 것으로 끝내지 말고, 실제 호출되는 reviewer의 편집 규칙을 확인합니다. 위임 자체가 필요 없는 흐름이라면 부모의 subagent 동작을 제한하는 선택도 있습니다.
여러 역할에서 공통으로 막아야 하는 도구 동작이라면 일반 역할 설정보다 policies의 tool.use 거부를 검토할 수 있습니다. 개인 전역 설정의 정책은 프로젝트 정책보다 우선하지만, 그 파일을 사용자가 고칠 수 있는지까지 해결하지는 않습니다. 팀이 관리하는 규칙이라면 관리 주체와 파일 위치도 함께 정해야 합니다. 설정 위치별 정책 우선순위는 공식 정책 문서에 설명돼 있습니다.
API로 작업을 만드는 도구라면 역할 설정만 볼 것이 아니라 생성 요청의 세션 권한도 살펴야 합니다. 이 경로는 부모 역할을 바꾸지 않고 특정 작업에 제한을 붙이는 데 의미가 있지만, 자식 생성 시 명시적으로 다른 규칙을 넣으면 상속 결과도 달라집니다. 이미 실행 중인 작업을 포함한 변경 전파는 별도로 검증해야 합니다.
여기서의 편집 금지는 OpenCode의 edit 권한 검사 범위입니다. 셸 명령, MCP 도구, 플러그인 코드가 만드는 변경까지 모두 막힌 읽기 전용 환경이나 운영체제 샌드박스를 뜻하지 않습니다. 셸은 호스트 사용자의 권한으로 실행되며, 정책도 플러그인 코드를 격리하지 않습니다. 셸 권한의 한계와 정책의 적용 한계를 함께 봐야 합니다.
백그라운드 검토를 도입할 이유가 있다면, 실제 업무 파일을 맡기기 전에 폐기 가능한 사례에서 부모의 위임과 자식의 도구 요청을 따로 확인하는 것이 좋습니다. 모델에 보내는 요청 내용은 설정한 제공자나 엔드포인트로 전달됩니다. 로컬에서 도구를 실행해도 모델 요청까지 로컬에 머무르는 것은 아니므로, 제공자·엔드포인트 설정과 이용 조건·호출 비용을 함께 확인해야 합니다. 1.x 플러그인이나 서버 연동에 의존하고 있다면 해당 연동의 이전을 확인할 때까지 기존 흐름을 유지할 수 있습니다. 이 글의 결론은 규칙 이름보다 규칙이 저장된 위치와 실제로 실행하는 에이전트를 먼저 확인하자는 것입니다.
공개 자료를 AI의 도움으로 조사·대조해 작성했습니다. 운영 경험이나 실행 검증으로 소개한 내용은 없습니다.
댓글
댓글 쓰기