mvschwarz/openrig

하네스(harness)가 모델을 감싸고, 리그(rig)가 당신의 하네스를 감쌉니다. YAML로 에이전트 팀을 정의하고 한 번의 명령으로 부팅하세요. Claude Code와 Codex를 같은 리그에서 관리되는 하나의 시스템처럼 사용합니다.

OpenRig은 자체 에이전트 네트워크를 구축하고 실행하기 위한 오픈 소스 소프트웨어입니다. AI 코딩 에이전트를 터미널 세션 더미가 아닌 지속적이고 체계적인 팀으로 바꿔줍니다. 원하는 결과에 대해 리드 에이전트와 대화하면, 이 에이전트는 팀 전반의 전문가들을 조정하여 당신의 주의가 필요한 결과물과 결정을 가져다줄 수 있습니다. 저장소(repository)와 유용한 변경 사항 하나로 시작한 다음, 팀의 작업 내용과 컨텍스트를 같은 주소에 유지할 수 있습니다.

이것은 저의 AI 문명 실험 뒤에 있는 오픈 소스 시스템입니다.

가이드: 시작하기 · 막혔나요? 도움말 · 질문: Q&A · 업데이트 및 데모: X에서 @_feralmachine 팔로우

여기서 시작하세요: 안내된 첫 사용 경로: 설치하고, 저장소에 두 에이전트 팀을 실행한 다음, 검토된 변경 사항 하나를 얻으세요.

오늘 설정할 시간이 없나요? 다음 워크스루와 간헐적인 OpenRig 업데이트를 받으려면 → https://openrig.dev/follow

macOS 또는 Linux에서 Node.js 22 또는 24와 tmux가 필요합니다. Linux의 경우, 배포판 자체의 Node.js 버전이 더 오래될 수 있습니다 (Ubuntu 24.04는 18입니다). nvm (nvm install 22) 또는 NodeSource를 사용하여 지원되는 버전을 설치하세요. Apple silicon을 탑재한 Mac에서는 Node.js 22를 사용하세요 (호환성 이력 참고). 네이티브 Windows는 아직 지원되지 않으며, WSL2도 테스트되지 않았습니다. 리그를 실행하는 것은 제공자 후크(provider hooks)와 작업 공간 신뢰 설정(workspace trust settings)을 작성합니다. 아래 명령을 실행하기 전에 OpenRig이 당신의 시스템에서 무엇을 변경하는지 읽고 관련 파일을 백업하세요.

한 번의 명령. 이 명령어는 v0.6.6 릴리스의 OpenRig 설치 스크립트를 실행합니다. Node.js와 npm을 확인하고, 최신 게시된 @openrig/cli를 npm install -g로 설치하며, Node.js 및 SQLite 검사를 수행한 다음, rig setup --dry-run과 rig setup을 실행합니다. 첫 번째 줄은 계획을 출력할 뿐 아무것도 변경하지 않습니다:

만약 제공자(provider)에 아직 로그인하지 않았다면, 마지막 단계에서 FAILED [4/4]가 보고되며, rig setup은 "처리할 몇 가지 단계가 필요합니다(Some steps need attention)" 아래에 로그인을 나열합니다. 만약 남아 있는 실패 항목들이 오직 제공자 로그인만 관련된 것이라면, 설치 단계는 완료된 것입니다. 아래와 같이 선택한 각 제공자에 로그인하고 계속 진행하십시오.

또는 단계별로:

npm install -g @openrig/cli
rig setup --dry-run

Bun을 사용하여 설치하려면 bun add -g @openrig/cli를 실행합니다. OpenRig은 여전히 Node.js에서 실행되므로, Node.js 22도 함께 설치해야 합니다. Bun이 이 패키지의 postinstall 스크립트를 차단할 수 있으며, 이런 경우 "OpenRig이 사용자의 장치에서 변경하는 것(what OpenRig changes on your machine)" 아래 설명된 Node.js 및 SQLite 확인 과정은 설치 시점에 실행되지 않습니다.

npm 11 이상 버전에서는 해당 postinstall 스크립트를 건너뛰고 npm warn install-scripts라는 경고를 출력할 수 있습니다. 이는 @openrig/cli에 대한 것입니다. 이는 예상된 동작입니다: CLI는 여전히 작동하며, Node.js 및 SQLite 확인만 건너뛴 것입니다. 직접 실행하려면 node "$(npm root -g)/@openrig/cli/scripts/check-abi.mjs"를 사용하십시오;

; rig doctor``은 Node.js 버전만 확인합니다.

이미 가지고 있는 작업 계정(working account)을 선택하세요: Claude Code, Codex 또는 둘 다. 명시적인 선택을 재사용하면 되며, 두 번째 구독이 필요하지 않습니다. rig setup --dry-run은 더 광범위한 설정을 미리 보여주지만, rig setup을 적용하는 것은 하네스(harnesses)를 모두 확인하고 누락된 것을 설치하며, macOS의 경우 cmux에서도 그렇게 합니다. 이는 선택적이며, 선택한 제공자 경로에 대해서만 해당됩니다.

권한 정책이 없는 팀 좌석(team seat), 좌석별 선택 또는 (Codex의 경우) 이름 지정 프로필로 실행하면 OpenRig의 팀 기본값으로 시작합니다: Claude는 일반적인 rig 명령, 프로젝트 읽기 및 공통 테스트를 프롬프트 없이 실행하며, rig up이나 rig down과 같은 라이프사이클(lifecycle) 명령어는...

여전히 묻습니다. Codex는 또한 OpenRig 작업 공간과 해당 pod의 상태 디렉터리를 쓰기 가능한(writable) 디렉터리로 얻습니다. 실행하기 전에, 에이전트는 기본 설정을 유지할 것을 권장하며, 사용자가 명시적으로 사용자 전체 세션(user-wide sessions)을 선택하지 않는 한, 개인 프로젝트 범위에서만 선택된 OpenRig 명령어를 네이티브 설정에 기억할지 여부를 제안합니다. 이는 전역적인 YOLO나 작업 내용을 임의로 만들 수 있는 권한이 아닙니다. '예(Yes)'를 누르면 에이전트는 네이티브 규칙을 추가하고 확인하며, '아니요(No)' 또는 응답 없음은 팀 기본 설정을 유지하고 설정을 변경하지 않습니다. 기존의 명시적 선택 사항은 재사용됩니다. 이 설정으로 추가된 OpenRig 명령어 허용을 제거하려면 “Undo the OpenRig command allowances added by this setup”이라고 말하십시오.

tmux -V를 확인하고
그리고 사용자가 선택한 CLI/로그인만: claude --version
플러스
claude auth status
, 또는 codex --version
플러스 codex login status
.
필요한 경우,
claude auth login이나 codex login으로 한 번 로그인하십시오;
사용하지 않는 프로바이더에 설치하거나 로그인하지 마십시오.

설치 후, 에이전트는 **새로운 커널 대화 공간(new kernel conversation space)**을 엽니다: rig terminal open saved:kernel --provider herdr
그 다음 cmux 또는 일반 터미널을 사용합니다. 기본 보기에는 YAML 편집이 필요 없습니다. 에이전트는 열기 전에 사용자에게 알려주고 자체 터미널과 기존 공간은 그대로 유지합니다. 가이드에는 수동 및 SSH 명령어도 제공됩니다.

커널의 운영자(operator)는 첫 번째 팀을 선택하는 데 도움을 줍니다. 무엇을 구축하고 싶은지 물어보고, 세 가지 중 하나를 추천하며, 사용 가능한 프로바이더에 맞춥니다.

출고된 상태로, starter

Claude Code와 Codex 모두를 사용합니다. 둘 중 하나만 사용할 경우, 커널 오퍼레이터에게 적응하도록 요청하십시오. 그러면 동일한 이름으로 제공업체들을 위한 팀 사본을 작성해 줍니다. first-project

is starter의 이전 이름이며 여전히 이를 시작하지만, 이미 first-project 또는 starter라는 이름의 rig가 있는 경우에는 거부합니다.
그리고 해당 rig를 다시 가져오는 rig up <name> --existing 명령을 사용하십시오.
실행 전에 선택된 런타임, 구성된 모델 및 명령어를 표시하고, 계정이 자동으로 폴백(fallback)하는 대신 모델을 지원하는지 확인하십시오. 커널은 자동으로 시작되며 이러한 팀들과는 독립적으로 사용 가능한 인증된 제공업체들 중에서 선택합니다. 누락되거나 사용하지 않는 제공업체는 설정 요구 사항이 아닙니다.

대신 직접 starter를 실행하려면(오퍼레이터가 없는 수동 경로):

cd /path/to/your/repository
rig specs preview starter --kind rig
rig up starter --cwd . --plan
...

커널은 별도의 운영 지원과 공유 대시보드를 제공합니다. 대시보드를 중지하지 않고 분리하려면 Ctrl-b를 누른 다음 d를 누르십시오. rig tui --shared는 해당 뷰로 돌아갑니다. 일반적인 rig tui는 독립적인 뷰를 엽니다. 보기 터미널을 닫는 것이 팀을 다시 시작해야 한다는 의미는 아닙니다.

rig ps --nodes --rig starter로 프로젝트 좌석(project-seat) 준비 상태를 확인하고, 작업을 할당하기 전에 인증, 신뢰 또는 권한 프롬프트를 해결하십시오. 만약 좌석이 시작 컨텍스트가 도착하기 전에 그러한 프롬프트에서 멈췄다면, rig ps는 해당 프롬프트에 답변하면 전달하는 rig seat continue <seat> 명령을 보여줍니다. 그런 다음 빌더에게 리포지토리에서 한 가지 제한된 결과물을 제공하십시오:

rig send dev-build@starter 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-review in this rig to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination dev-build@starter --limit 1000

메시지를 보내는 것 자체가 큐 항목을 생성하는 것은 아니며, 빌더가 작업을 기록합니다. 최종 아티팩트와 정확한 후보에 대한 검토를 읽은 다음, 다음 변경 사항을 위해 동일한 빌더로 돌아가세요. 안내된 첫 사용 경로는 준비 상태(readiness), 유용한 작업, 검토된 결과, Herdr/cmux 터미널 및 복구 과정을 다룹니다.

오늘 설정할 수 없나요? 다음 워크스루와 가끔 올라오는 OpenRig 업데이트를 받으세요 → https://openrig.dev/follow

질문: 토론 › Q&A 버그 및 기능 요청: 이슈 열기 기여: CONTRIBUTING.md · 행동 강령(Code of Conduct) · 보안 정책(Security policy) · 도움말 얻기 비디오: youtube.com/@openrig 릴리스: GitHub Releases 및 npm@openrig/cli

저희는 하루 이내에 이슈와 풀 리퀘스트를 인정하는 것을 목표로 합니다. 검토 대상은 CONTRIBUTING.md를 참조하세요.

OpenRig은 설정 및 운영의 일부로서 인스턴스 상태, 프로바이더 통합(provider integration), 그리고 작업 공간 파일(workspace files)을 작성합니다. 여기에는 **신뢰 설정(trust settings)과 실행 가능한 후크(executable hooks)**가 포함됩니다. 아래 요약은 이 소스 개정판을 따르며, 저장소 가이드가 npm보다 앞설 수 있으므로 패키지를 사용할 때는 rig --version을 확인하세요.

Git 저장소에서 .codex/plugins/shared:openrig-core/ (또는 명시되지 않은 .codex/plugins/openrig-core/) 아래에 새로 생성된 파일은 # BEGIN OpenRig generated files 블록 내부에 저장소의 Git info/exclude에 추가됩니다. 새로운 AGENTS.md, CLAUDE.md, 그리고 CLAUDE.local.md 파일은 경고와 함께 계속 표시됩니다. |
번들 설치(rig bundle install 또는 .rigbundle이나 GitHub 링크를 사용한 rig up) |
번들의 파일을 다음 위치에 작성합니다: --target 또는 rig up 및 GitHub 링크의 경우 현재 디렉토리입니다. 로컬 아카이브를 사용하는 rig bundle install은 --target이 필요합니다. 이는 선언된 스킬, 플러그인, 컨텍스트 팩을 라이브러리로 라우팅합니다. GitHub 링크의 아카이브는 OPENRIG_HOME/bundle-imports/ 아래에 유지되며, 설치 기록은 OPENRIG_HOME/bundle-audit.jsonl에 남겨집니다. 프로젝트를 포함하는 번들은 이를 workspace.projects_root 아래에 생성하고, 해당 리그(rig)와의 연관성을 가지고 워크스페이스 카탈로그에 기록합니다. |
명시적 권한 구성 |
내장 부트스트랩은 rig 명령어의 허용 규칙을 설정 파일에 추가하지 않습니다. 권한 정책이 없는 팀 좌석, 좌석별 선택 또는 (Codex의 경우) 이름 지정된 프로필을 가진 사용자는 대신 실행 시점의 팀 기본값을 받게 됩니다. 에이전트 안내 설정은 현재 상태를 유지할 것을 권장하며, 에이전트가 기억된 규칙을 선택한 범위에 추가하기 전에 실제 답변을 요구합니다. 아무것도/답변 없음은 팀 기본값을 유지하고 설정을 보존합니다. 기존의 선택 사항과 더 엄격한 규칙들은 여전히 유효합니다. 광범위한 접근 권한은 별개입니다. |

제공자 파일(provider files)은 인스턴스 상태와 분리되어 있습니다. 여기서 ~는 데몬 사용자 홈을 의미하며, 단순히 OPENRIG_HOME만 변경한다고 해서 제공자 구성이 격리되지는 않습니다.

**Claude Code:**startup은 워크스페이스 신뢰(trust) 및 온보딩 완료를 작성합니다. 명시적 권한 모드에서는 실행 선택된 HOME/.claude.json 또는 해당 변수가 설정된 경우 <CLAUDE_CONFIG_DIR>/.claude.json을 사용합니다. 클래식 스타트는 HOME/.claude.json과 또한 <CLAUDE_CONFIG_DIR>/.claude.json을 작성합니다.

데몬이 해당 변수를 설정했을 때입니다. 워크스페이스에서는 .claude/settings.local.json을 받습니다.

컨텍스트 컬렉터의 statusLine 명령어와 선택된 액티비티 훅(activity hooks)을 그리고; 헬퍼 스크립트는 .openrig/ 아래에 있습니다.

선택된 설정/MCP 리소스는 또한 해당 settings 파일과 .mcp.json을 변경할 수 있습니다.