Codex 훅이 하네스를 현실로 만든다

Codex 0.150.1(2026년 8월 27일) 기준으로 Codex 훅은 12개의 라이프사이클 이벤트를 등록하고, 비관리형 훅은 그 정의를 정확히 검토하고 신뢰하기 전까지 실행을 거부하며, 기본적으로 활성화된 상태로 제공됩니다. ChatGPT 모바일 앱과 함께 5월 14일 출시 번들에서 정식 출시된 이 기능은 이제 거버넌스 표면으로 성숙했습니다. PreToolUse는 도구 호출이 실행되기 전에 차단하거나 다시 쓸 수 있고, PermissionRequest는 승인을 결정할 수 있으며, PostToolUse는 모델이 보는 결과를 교체할 수 있고, Stop은 턴이 끝나는 것을 거부할 수 있습니다.²³

Codex는 더 이상 하나의 터미널 안에서 기다리는 코딩 어시스턴트처럼 보이지 않습니다. 이제는 머신, 승인, 프로젝트, 채팅, diff, 테스트, 스크린샷, 플러그인, 자격 증명, 로컬 도구를 넘나들며 작업을 따라다니는 운영 계층처럼 보입니다.⁴

Codex 훅이 하네스를 현실로 만듭니다. 에이전트가 휴대폰에서 작업하고, 원격 개발 환경에 접근하고, 라이프사이클 훅을 실행할 수 있게 되면, 팀에는 모델 주위의 제어 시스템이 필요합니다. 증거, 승인, git 커스터디, 소스 규율, 그리고 안목(taste)입니다.

TL;DR

Codex는 에이전트 팀들이 비공개로 구축해 온 워크플로 형태를 지원합니다. 장시간 실행 작업, 원격 실행, 모바일 조종, 승인, 훅, 범위가 제한된 자격 증명, 감사 신호가 그것입니다.²⁴⁵ 0.150.0의 훅 엔진은 12개 이벤트를 등록하고, 모든 비관리형 훅은 현재 해시를 신뢰하기 전까지 건너뛰어지며, 훅은 hooks.json 파일 또는 config.toml의 인라인 [hooks] 테이블에서 로드됩니다.³⁷ 실질적인 질문은 “Codex에 어떻게 프롬프트를 줄 것인가”가 아닙니다. 실질적인 질문은 “결과를 신뢰하기 전에 Codex가 무엇을 증명해야 하는가”입니다. 팀은 훅과 설정을 사용해 리뷰 게이트, 보안 경계, 공개 글쓰기 기준, 릴리스 규율을 인코딩해야 합니다. 비공개 장치는 비공개로 유지하고 패턴, 수용 기준, 검증된 결과만 공개해야 합니다.

핵심 요약

엔지니어링 팀이라면: - Codex 훅을 장식이 아니라 프로세스 인프라로 취급하세요. 신뢰 검토 흐름은 우회할 마찰이 아니라 그 인프라의 일부입니다. - 영리한 자동화를 추가하기 전에 증거, 승인, git 커스터디, 릴리스 점검부터 시작하세요.

에이전트 도구를 만드는 사람이라면: - Codex의 실제 표면을 중심으로 구축하세요. 모바일 제어, Remote SSH 호스트, 샌드박스 모드, 승인 정책, 프로젝트 지침, 훅, 텔레메트리, 버전 관리가 그것입니다. - 예전 슬래시 명령 형태가 아니라 해결해야 할 일(jobs-to-be-done)을 이식하세요.

공개 글을 쓰는 사람이라면: - 현재 Codex 동작에는 learn.chatgpt.com의 공식 문서를 사용하고, 문서가 릴리스보다 뒤처질 때는 엔진 소스를 확인하세요. - 비공개 관행은 저자 분석으로 서술하고, 비공개 프롬프트, 훅 본문, 파일 경로, 소스 목록, 자격 증명, 스코어링 내부 구조는 공개 글에서 빼세요.

Codex 훅은 어디에서 왔나요?

OpenAI는 2026년 5월 14일 “Work with Codex from anywhere”(어디서나 Codex로 작업하기)를 게시했습니다.¹ 같은 날짜의 문서 변경 로그 항목에는 출시 번들이 기록되어 있습니다. Codex 앱이 실행 중인 Mac에 연결해 ChatGPT 모바일 앱에서 Codex를 사용할 수 있게 되었고, 훅이 정식 출시에 도달했으며, 신뢰된 자동화를 위한 Codex 액세스 토큰이 도착했습니다.² Codex는 연결된 호스트에서 실행되므로 같은 프로젝트, 파일, 자격 증명, 플러그인, 스킬, 설정을 휴대폰에서도 그대로 사용할 수 있습니다.²

원격 연결은 작업 범위를 하나의 책상 너머로 확장합니다. 발표문의 Remote SSH 기능은 문서에서 SSH 호스트로 자리 잡았습니다. ChatGPT 데스크톱 앱은 SSH 호스트에서 원격 프로젝트를 추가하고 원격 파일시스템과 셸을 대상으로 채팅을 실행할 수 있습니다. 그 표현은 구체적입니다: “Remote access uses the connected host’s projects, chats, files, credentials, permissions, plugins, Computer Use, browser setup, and local tools.”(원격 접근은 연결된 호스트의 프로젝트, 채팅, 파일, 자격 증명, 권한, 플러그인, Computer Use, 브라우저 설정, 로컬 도구를 사용합니다)⁴

훅 자체는 출시 전부터 실험으로 존재했고, 이후에는 실험 수준을 넘어 성장했습니다. 문서는 훅을 에이전트 루프 중에 스크립트나 MCP 도구를 실행하는 확장성 프레임워크로 정의하고, 일상적인 역할을 명확히 나열합니다. 채팅을 로깅 엔진으로 보내기, 실수로 붙여넣은 API 키 차단하기, 채팅을 영구 메모리로 요약하기, 턴이 멈출 때 검증 점검 실행하기, 디렉터리별로 프롬프트 커스터마이즈하기가 그것입니다.³ 훅은 이제 기본적으로 활성화되어 있습니다. config.toml의 features.hooks가 킬 스위치 역할을 하고, features.codex_hooks는 지원 중단된 별칭으로만 남아 있습니다.³⁶

이 세부 사항이 중요한 이유는 에이전트 작업을 채팅 주고받기에서 통제되는 운영으로 바꾸기 때문입니다.

설정에서 Codex 훅은 어떤 모습인가요?

훅에 관한 글이라면 훅을 보여줘야 합니다. Codex는 활성 설정 계층 옆에서 훅을 발견하는데, 가장 유용한 위치는 ~/.codex/hooks.json, <repo>/.codex/hooks.json, 또는 두 계층 중 어느 쪽이든 그 config.toml의 인라인 테이블입니다. 소스가 여러 개 있으면 일치하는 훅이 모두 로드되어 실행됩니다.³ 도구 게이트와 완료 게이트를 담은 최소한의 hooks.json은 다음과 같습니다:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/pre_tool_use_policy.py",
            "timeout": 30,
            "statusMessage": "Checking Bash command"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/evidence_gate.py"
          }
        ]
      }
    ]
  }
}

같은 형태를 config.toml에 인라인으로 쓰면 다음과 같습니다:

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking Bash command"

모든 훅은 세 수준으로 구성됩니다. 이벤트, 이벤트가 적용되는 시점을 정하는 matcher 그룹, 그리고 하나 이상의 핸들러(command 또는 mcp_tool)입니다.³ 엔진의 12개 항목 목록을 권위 있는 기준으로 삼은 현재 이벤트는 다음과 같습니다:³⁷

라이브 훅 문서는 아직 이 이벤트 중 11개만 문서화하고 있으며 Interrupt 섹션이 아직 없습니다. 열두 번째는 0.150.0 변경 로그 항목(#40511)과 rust-v0.150.0 엔진 소스의 HOOK_EVENT_NAMES: [&str; 12]가 담고 있습니다.²⁷ 페이지와 엔진이 다르게 말하면 엔진을 신뢰하세요.

훅은 실제로 어떤 도구 호출을 볼 수 있나요?

예전 버전의 문서는 PreToolUse가 셸과 MCP 호출 외에는 거의 다루지 못한다고 경고했습니다. 현재 문서는 그 표면을 넓힙니다: “PreToolUse and PostToolUse can observe more than shell and MCP calls. Most local function tools use the same hook path,”(PreToolUse와 PostToolUse는 셸과 MCP 호출 이상을 관찰할 수 있으며, 대부분의 로컬 함수 도구가 같은 훅 경로를 사용합니다) 따라서 matcher는 update_plan 같은 도구를 직접 지명할 수 있고, spawn_agent는 Agent로도 매칭됩니다.³ 셸 명령은 Bash로 매칭되고, apply_patch 파일 편집은 apply_patch, Edit, 또는 Write로 매칭되며, MCP 도구는 mcp__filesystem__read_file 같은 이름으로 매칭됩니다.³

호스팅된 도구는 여전히 바깥에 있습니다. WebSearch와 그 동류는 로컬 함수 도구 훅 경로를 절대 거치지 않습니다.³ 문서는 전체를 인용할 가치가 있는, 완화된 주의 문구를 유지하고 있습니다: “Some specialized tool paths can opt out of the default hook path. Treat tool hooks as a useful guardrail, not a complete enforcement boundary.”(일부 특수한 도구 경로는 기본 훅 경로에서 빠질 수 있습니다. 도구 훅은 완전한 강제 경계가 아니라 유용한 가드레일로 취급하세요)³ 단단한 경계는 여전히 샌드박스가 담당하고, 훅은 그 안에서 검토와 조종을 담당합니다.

Codex는 어떤 훅이 실행될 수 있는지 어떻게 결정하나요?

훅은 에이전트를 조종하는 코드이므로 Codex는 훅 자체를 통제합니다. 모델 주위의 제어 시스템은 여기서 시작됩니다.

비관리형 훅이 실행되기 전에 Codex는 그 정의를 정확히 검토하고 신뢰할 것을 요구합니다. 신뢰는 훅의 현재 해시에 대해 기록되므로, 새로 만들거나 수정한 훅은 검토 대상으로 표시되고 다시 신뢰하기 전까지 건너뛰어집니다.³ CLI의 /hooks 명령이 검토 표면을 엽니다. 훅 소스를 살펴보고, 새로 생기거나 바뀐 훅을 검토하고, 신뢰하고, 개별 훅을 비활성화할 수 있습니다. 시작 시 검토가 필요한 훅이 있으면 Codex는 /hooks를 가리키는 경고를 출력합니다.³

시스템, MDM, 클라우드, 또는 requirements.toml 소스에서 오는 관리형 훅은 이 흐름 위에 있습니다. 정책에 따라 신뢰되며 사용자 훅 브라우저에서 비활성화할 수 없습니다.³ 플러그인은 이 흐름 안에 있습니다. 플러그인을 설치하거나 활성화해도 번들된 훅이 신뢰되지는 않으며, 다른 훅과 마찬가지로 검토 전까지 건너뛰어집니다.³ 프로젝트 로컬 훅은 프로젝트의 .codex/ 계층이 신뢰될 때만 로드되고, 신뢰되지 않은 프로젝트에서도 사용자 훅과 시스템 훅은 여전히 로드됩니다.³

자동화에도 같은 규칙이 적용됩니다. codex exec 실행에는 검토 UI가 없으므로, 신뢰되지 않은 훅은 먼저 대화형 세션에서 신뢰하기 전까지 조용히 건너뛰어집니다. 문서에는 아직 그렇게 적혀 있지 않지만, 엔진의 시작 시 검토 표면은 대화형 TUI에만 존재합니다.⁷ 훅 소스를 다른 곳에서 검증하는 파이프라인을 위해 --dangerously-bypass-hook-trust는 그 한 번의 호출에 한해 신뢰를 저장하지 않고 활성화된 훅을 실행합니다.³ 의도적으로 신뢰하지 않으면 게이트가 작동하지 않는 모습을 지켜보게 됩니다. 어떤 코드가 에이전트를 조종할 수 있는지는 그 코드가 실행되기 전에 하네스가 결정합니다.

훅이 차단하면 무슨 일이 일어나고, 언제는 이미 늦은가요?

훅이 아직 바꿀 수 있는 것은 타이밍이 결정합니다. 대부분의 훅은 기본 타임아웃 600초로 동기 실행됩니다. SessionEnd와 Interrupt는 기본 1초에 상한 3초입니다. SessionEnd는 세션이 정리되는 동안 발생하고, Interrupt는 사용자가 기다리는 동안 발생하기 때문입니다.³⁷

PreToolUse는 아무 일도 일어나기 전에 작동하므로 가장 강력한 카드를 쥐고 있습니다. 호출을 거부하거나, updatedInput과 함께 permissionDecision: "allow"를 반환해 호출을 다시 쓸 수 있습니다. 거부 형태는 다음과 같습니다:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook."
  }
}

stderr에 사유를 담은 종료 코드 2도 차단합니다.³

PostToolUse는 도구가 실행된 후에 작동하므로 부작용을 되돌릴 수 없습니다. decision: "block"은 도구 결과를 여러분의 피드백으로 교체하고 그 메시지에서부터 모델을 계속 진행시키는데, 이는 명령이 없었던 척하지 않으면서 경로를 교정합니다.³ Stop은 거부를 계속 진행으로 바꿉니다. 완료를 차단하면 Codex는 여러분의 사유를 새 프롬프트로 삼아 계속 작업합니다.³

임계 경로에 절대 놓여서는 안 되는 점검에는 command 핸들러에 async = true를 설정하세요. 백그라운드 훅은 Codex가 계속 진행되는 동안 실행되고, 다음 안전 지점에서 출력을 전달하며, 명시적으로 아무것도 차단, 승인, 재작성할 수 없습니다. 도구 정책, 권한 결정, 프롬프트 거부, 턴 계속 여부는 동기로 유지하세요.³

0.149와 0.150에서는 무엇이 업그레이드되었나요?

8월 말의 stable 릴리스 두 개가 거버넌스 이야기를 더 조였습니다.

Codex CLI 0.149.0(2026년 8월 20일)은 untrusted 승인 정책을 폐지했습니다(#39630). 그 값을 여전히 지정하는 설정은 이제 해당 설정을 제거하라는 조치 가능한 오류와 함께 실패합니다.²⁷ Codex CLI 0.150.0(2026년 8월 26일)은 Interrupt 훅 이벤트를 추가했습니다(#40511): “New Interrupt hooks can run commands or MCP handlers when an active top-level turn is interrupted.”(새 Interrupt 훅은 활성 최상위 턴이 중단될 때 명령이나 MCP 핸들러를 실행할 수 있습니다) Interrupt 훅은 서브에이전트에 대해서는 절대 실행되지 않습니다.²⁷ 같은 릴리스는 신뢰되지 않은 프로젝트가 프로젝트 수준 AGENTS.md 지침을 제공하는 것을 막았는데(#39837), 이는 프로젝트 로컬 훅이 신뢰된 .codex/ 계층에서만 로드된다는 기존 규칙과 짝을 이룹니다.²³

방향은 일관됩니다. 신뢰되지 않은 디렉터리는 그 안에 들어온 에이전트에 대해 점점 더 적은 권한을 갖습니다. 지침, 훅, 승인 단축 경로 모두 이제 명시적인 신뢰 결정을 거칩니다.

훅이 모바일보다 더 중요한 이유는 무엇인가요?

모바일 접근은 사람이 개입할 수 있는 위치를 바꿉니다. 훅은 시스템이 강제할 수 있는 내용을 바꿉니다.

휴대폰은 운영자가 책상에서 떨어져 있는 동안에도 질문에 답할 수 있게 합니다. 훅은 위험한 행동 전, 파일 편집 후, 완료 전, 또는 릴리스 점검 중에 에이전트를 붙잡을 수 있습니다. 휴대폰은 지연을 해결하고, 훅은 기준을 해결합니다.

Codex에는 이미 샌드박스와 승인을 둘러싼 자체 제어 표면이 있습니다. 안전 문서는 에이전트가 기술적으로 무엇을 할 수 있는지 정하는 샌드박스 모드와, Codex가 행동하기 전에 언제 멈추고 물어야 하는지 정하는 승인 정책을 짝지어 설명합니다.⁵ 에이전트는 기본적으로 네트워크 접근이 꺼진 상태로 실행되며, 기본 로컬 workspace-write 모드는 사용자가 켜지 않는 한 네트워크 접근을 끈 상태로 유지합니다.⁵ 훅은 샌드박스의 대체물이 아니라 검토와 조종 계층으로서 이 제어 장치들 옆에 자리합니다.

훅은 로컬 기준을 실행 가능하게 만들 수 있습니다:

모델은 규칙을 잊을 수 있습니다. 훅은 규칙이 중요해지는 바로 그 순간에 규칙을 다시 실행할 수 있습니다.

하네스는 제공자가 갖지 않은 무엇을 소유하나요?

에이전트 하네스는 모델 주위의 운영 계층입니다. 권한, 메모리, 도구, 훅, 소스 점검, 릴리스 게이트, 리뷰 패킷, 롤백 규율이 그것입니다. 이 용어는 사적이거나 화려하게 들릴 수 있지만 역할은 단순합니다. 이 계층은 의도를 책임질 수 있는 작업으로 바꿉니다.

Codex는 이제 그 계층을 명시적으로 만들 만큼 충분한 공식 표면을 노출합니다. 원격 연결은 호스트 환경을 실어 나릅니다. 샌드박스 모드와 승인 정책은 행동 경계를 정의합니다. 설정 파일은 모델, 프로젝트, 권한, MCP 서버, 스킬, 훅, 텔레메트리, 기능을 정의합니다.⁶ OpenTelemetry 내보내기는 옵트인 방식으로 기본적으로 꺼져 있습니다. 활성화하면 Codex는 채팅, API 요청, 스트림 활동, 사용자 프롬프트(기본적으로 마스킹됨), 도구 승인 결정, 도구 결과를 아우르는 구조화된 이벤트를 내보냅니다.⁵⁸

이 표면들의 집합은 유용한 분담을 만듭니다:

제공자는 런타임을 계속 개선해야 합니다. 판단은 여전히 팀의 몫입니다.

팀은 무엇을 먼저 인코딩해야 하나요?

네 가지 게이트로 시작하세요. 이 게이트들은 즉시 제값을 합니다.

증거 게이트

Codex의 원래 출시 글은 검증 가능한 증거를 강조했습니다. 터미널 로그, 테스트 출력, 작업 완료 과정의 추적 가능한 단계가 그것입니다.⁹ 그 기대를 협상 불가능한 것으로 만드세요. 의미 있는 완료라면 변경된 파일, 실행한 명령, 관찰된 동작, 실패한 점검, 남은 공백을 구체적으로 밝혀야 합니다.

공개 작업이라면 증거에 소스 링크와 주장-소스 정합성이 포함됩니다. 웹 릴리스라면 렌더링된 라우트, 메타데이터, 스키마, 디스커버리 파일, 배포 상태, 캐시 신선도, 라이브 변경 마커가 포함됩니다. 번역이라면 로캘 커버리지, 품질 게이트, 스토리지 행 또는 캐시 파일, 그리고 필요한 경우 원어민 검토 상태가 포함됩니다.

승인 게이트

모든 행동에 하나의 승인 자세를 쓰지 마세요. 승인 문서의 현재 조합 표는 Auto 프리셋(workspace-write 샌드박스와 on-request 승인)에서 시작해 안전한 읽기 전용 탐색, 읽기 전용 비대화형 CI, 자동 리뷰 모드, 위험한 전체 접근까지 이어집니다.⁵ 한 행은 현실보다 뒤처져 있습니다. untrusted 정책이 페이지에 여전히 나타나지만, 0.149.0이 이를 폐지했고 명시적 설정은 이제 오류가 납니다.²⁵ 오늘 항상 묻는 자세를 원한다면 read-only 샌드박스를 on-request 승인과 결합하세요. 강력한 로컬 정책도 같은 형태를 유지합니다. 위험이 낮은 읽기는 조용히 통과하고, 부작용이 있는 작업은 리뷰를 받고, 파괴적이거나 외부에 보이는 작업은 명시적 증거를 요구받습니다.

Git 커스터디 게이트

에이전트 작업에는 롤백 손잡이가 필요합니다. Codex 자체의 보안 문서는 Codex가 버전 관리와 함께할 때 가장 잘 작동한다고 말합니다. 위임하기 전에 상태를 깨끗하게 유지하고, 자주 커밋하고, 표적 검증을 실행하고, diff를 검토하고, 커밋 메시지에 결정을 문서화하라는 것입니다.⁵

이 조언은 프로세스가 되어야 합니다. 일관되고 검증된 저장 지점 이후에 커밋하세요. 정확한 경로를 스테이징하세요. 독립적으로 되돌릴 수 있는 관심사별로 커밋을 나누세요. 릴리스 흐름이 이미 게시 권한을 부여한 경우가 아니라면 푸시 전에 물어보세요. 에이전트의 눈에 우연히 띄었다는 이유로 무관한 더러운 파일을 커밋에 쓸어 담지 마세요.

안목 게이트

AI 코딩은 구현을 더 저렴하게 만듭니다. 구현이 저렴해질수록 안목의 가치는 올라갑니다.

안목은 장식적 취향을 뜻하지 않습니다. 작업이 제품 전체를 개선한다는 뜻입니다. 결과를 약화시키는, 기술적으로는 가능한 경로를 에이전트가 거부할 수 있다는 뜻입니다. 공개 글이 비공개 장치, 근거 없는 주장, 채우기용 문장을 피한다는 뜻입니다. 사용자에게 보이는 경로가 여전히 망가져 있다면 올바른 로컬 패치도 실패할 수 있다는 뜻입니다.

안목 게이트는 이렇게 물어야 합니다:

Mozilla의 Firefox 작업은 무엇을 증명하나요?

Claude Mythos Preview로 Firefox를 강화하는 것에 관한 Mozilla의 5월 7일 글은 다른 스택에서 같은 요점을 짚습니다. 팀은 초기 LLM 코드 감사 시도가 가능성을 보였지만 규모를 키우기에는 오탐이 너무 많았다고 말합니다. 에이전트 하네스는 버그 가설을 동적으로 시험할 재현 가능한 테스트 케이스를 만들고 실행할 수 있었기 때문에 경제성을 바꿔 놓았습니다.¹⁰

Mozilla의 중요한 문장은 모델 하나만을 다루지 않습니다. 팀은 발견이 필요조건이지 충분조건은 아니었다고 말합니다. 유용한 시스템은 보안 버그 라이프사이클 전체와 통합되어야 했습니다. 대상 선정, 중복 제거, 버그 추적, 분류, 수정, 릴리스가 그것입니다.¹⁰ 저자들은 파이프라인이 Firefox 코드베이스의 의미 구조, 도구, 프로세스를 반영했다고도 말합니다.¹⁰

이것이 Codex에 주는 교훈입니다. 더 나은 모델은 중요합니다. 작업이 신뢰받는 산출물이 되는지는 모델 주위의 운영 시스템이 결정합니다.

공개 글에서 빠져야 하는 것은 무엇인가요?

공개 Codex 글이 비공개 작업 시스템을 쏟아 놓아서는 안 됩니다.

다음은 공개 글에서 빼세요:

• 비공개 프롬프트와 훅 본문;
• 민감한 로컬 경로;
• 정확한 소스 맵과 스코어링 내부 구조;
• 계정 식별자와 자격 증명 처리 방식;
• 비공개 워크플로 단축 경로;
• 출시되지 않은 플러그인 동작;
• 낯선 사람이 내부 운영을 재구성하는 데 도움이 되는 모든 것.

대신 패턴을 공개하세요. 게이트가 무엇을 보호하는지, 어떤 증거를 요구하는지, 어떤 실패를 잡아내는지, 그리고 팀이 공식 Codex 표면을 사용해 그 아이디어를 어떻게 구현할 수 있는지를 공개하는 것입니다.

이 선은 신뢰를 보호합니다. 글도 좋아집니다. 비공개 장치는 대개 민간 설화처럼 읽힙니다. 공개된 수용 기준은 다른 팀이 자기 시스템에 대해 추론하는 데 도움이 됩니다.

최소한의 Codex 하네스 지도는 어떤 모습인가요?

유용한 작업을 증명하는 가장 작은 제어 지도를 만드세요.

명시적으로 시작하세요. 실제 작업 하나를 실행하세요. 게이트가 도움이 된 곳과 방해가 된 곳을 기록하세요. 사용자에게 보이는 결과를 개선하는 부분만 승격하세요.

빠른 요약

Codex 훅, Remote SSH, 모바일 제어, 샌드박스, 승인, 설정, 텔레메트리, 버전 관리는 모두 같은 방향을 가리킵니다. 코딩 에이전트에는 그 주위의 운영 체제가 필요합니다.²⁴⁵⁶ 에이전트는 코드를 쓸 수 있습니다. 무엇이 작업으로 인정되는지는 하네스가 결정합니다.

최고의 팀은 에이전트 산출물을 가장 많이 만들어서 이기지 않을 것입니다. 에이전트 작업을 검사 가능하고, 되돌릴 수 있고, 출처가 분명하고, 안목 있고, 릴리스할 가치가 있게 만들어서 이길 것입니다.

자주 묻는 질문

Codex 훅이란 무엇인가요?

Codex 훅은 에이전트 루프 중에 스크립트나 MCP 도구를 실행하며, hooks.json 파일 또는 config.toml의 인라인 [hooks] 테이블에서 로드됩니다. 문서는 그 역할을 명확하게 나열합니다. 채팅을 로깅 엔진으로 보내기, 실수로 붙여넣은 API 키 차단하기, 채팅을 영구 메모리로 요약하기, 턴이 멈출 때 검증 실행하기, 디렉터리별로 프롬프트 커스터마이즈하기입니다.³ 0.150.0의 엔진은 PreToolUse, PermissionRequest, PostToolUse부터 Stop과 새로운 Interrupt까지 12개 이벤트를 등록합니다. 문서 페이지는 따라잡는 동안 아직 11개만 나열하고 있습니다.³⁷

Codex 훅이 왜 중요한가요?

훅은 프롬프트에만 의존하는 대신 결정 지점에 기준을 둘 수 있게 합니다. 훅은 에이전트가 행동하거나 끝내려고 할 때 증거, 소스 품질, git 상태, 릴리스 준비 상태를 점검할 수 있습니다.

내 훅이 왜 실행되지 않았나요?

보통은 신뢰가 답입니다. Codex는 현재 해시를 검토하지 않은 비관리형 훅을 모두 건너뛰며, 대화형 세션에서는 시작 시 경고를 출력하고 codex exec 자동화에서는 조용히 건너뜁니다.⁷ /hooks를 열어 검토하고 신뢰하거나, 훅 소스를 다른 곳에서 검증하는 파이프라인에서만 --dangerously-bypass-hook-trust를 넘기세요.³

Codex 모바일이 로컬 에이전트 워크플로를 대체하나요?

아니요. 모바일 제어는 사용자가 책상에서 떨어져서도 작업을 조종할 수 있게 하지만, 프로젝트, 채팅, 파일, 자격 증명, 권한, 플러그인, 로컬 도구는 여전히 연결된 호스트가 제공합니다.⁴ 팀에는 여전히 로컬 정책, 안전한 자격 증명, 버전 관리, 검증이 필요합니다.

Codex 하네스에는 무엇을 먼저 포함해야 하나요?

프로젝트 지침, 샌드박스와 승인 자세, 비밀 경계, 증거 중단 게이트, 정확한 경로의 git 커스터디, 공개 주장에 대한 소스 검증, 사용자에게 보이는 작업을 위한 릴리스 게이트로 시작하세요.

팀이 자신의 Codex 훅을 공개해야 하나요?

비공개 훅 본문이나 민감한 워크플로 세부 사항이 아니라 패턴과 수용 기준을 공개하세요. 유용한 공개 글은 비공개 경로, 소스 맵, 프롬프트, 자격 증명, 스코어링 규칙을 노출하지 않고도 훅의 역할을 설명할 수 있습니다.

참고 자료