에이전트 루프

매 턴마다 Codex는 같은 루프를 실행합니다. 이해하는 것이 가장 영향력이 큰 일입니다:

읽기 → 추론 → 제안 → 승인 → 적용 → 검증 루프

1. READ       — load relevant files, git status, prior turns
2. REASON     — decide the next action (run cmd? edit file? ask user?)
3. PROPOSE    — surface the action; if high-risk, pause for approval
4. APPLY      — execute the approved action
5. VERIFY     — re-read, run tests, check the result
       ↺ repeat until the goal is met or it asks for help

왜 중요한가: 챗봇은 텍스트를 내보냅니다. 에이전트는 행동하고, 결과를 관찰하고, 방향을 교정합니다. 루프는 Codex가 가치를 증명하는 곳이며 — 하네스(AGENTS.md, config, 승인 정책)가 유효 컨텍스트와 반복 품질을 형성하는 곳입니다.

스레드

**스레드(thread)**는 Codex에서 대화와 컨텍스트의 단위입니다. 각 스레드는 자체 메시지 기록과 누적 상태를 갖습니다. 실무적 함의:

• 스레드당 한 작업 — 관련 없는 작업을 한 스레드에 쌓지 마십시오; 컨텍스트가 썩습니다.
• 이어하기(Resume) — Codex는 이전 스레드를 이어가며 누적된 컨텍스트를 그대로 가져올 수 있습니다.
• 병렬 — 데스크톱 앱과 worktree가 여러 스레드를 간섭 없이 동시에 실행하게 합니다 (탭 5 참고).

황금률

Codex는 목줄이 있는 유능한 파트너이지, 소원을 들어주는 우물이 아닙니다. 여러분의 역할은 방향을 주고, 만질 수 있는 경계를 그으며, 흐트러질 때 방향을 교정하는 것입니다.

이 한 문장이 좋은 결과를 얻을지 예측합니다. Codex는 마법이 아닙니다 — 방향 잡기가 필요한 강력한 실행자입니다. 목표를 주고(단계별 레시피가 아니라), 허용된 행동을 제한하고(샌드박스 + 승인), 잘못된 가정을 할 때 방향을 바꿔 주십시오.

컨텍스트 윈도우

매 턴 모델의 작업 메모리에 들어가는 것

Codex가 매 턴 사용하는 유효 작업 메모리는 유한합니다. 스레드가 커지면 이전 턴, 도구 출력, 파일 읽기가 누적됩니다. 두 가지 실무적 결과:

• 미리 압축하기 — /compact가 스레드를 요약해 공간을 되찾아 줍니다; 품질이 떨어진 뒤가 아니라 떨어지기 전에 하십시오.
• “1M 컨텍스트”가 1M 사용 가능은 아닙니다 — 시스템 프롬프트, 도구 정의, 검색된 파일이 큰 몫을 차지합니다; 작업에 사용할 수 있는 유효 예산은 표면적 숫자보다 훨씬 작습니다.

승인 모드와 샌드박스

Codex는 하나가 아니라 두 개의 독립적인 노브를 노출합니다. 초보자의 가장 흔한 혼란입니다:

세 가지 샌드박스 모드:

세 가지 승인 정책: untrusted (많이 묻기), on-request (일상 기본값), never (헤드리스/CI 전용).

💡 일상 개발용 황금 조합: workspace-write + on-request. 에이전트가 프로젝트 안에서 자유롭게 편집하되, 벗어나는 일 앞에서는 멈춥니다.

⚠️ --yolo = danger-full-access + never. 일회용 컨테이너를 위해 존재합니다. 실제 머신에서는 절대 실행하지 마십시오 — 사용자 파일을 삭제한 문서화된 사례가 있습니다.

모델과 추론 노력

두 개의 다이얼이 “Codex가 얼마나 깊이 생각하는지”를 결정합니다:

• 모델 (/model 또는 config의 model = "...") — 능력 대 비용으로 선택하십시오. 사소한 편집에 가장 강력한 모델을 기본으로 잡지 말고, 어려운 리팩터링에 인색하지 마십시오.
• 추론 노력(reasoning effort) (/effort 또는 노력 다이얼) — low/medium/high/xhigh. 모델을 바꾸는 것보다 영향력이 크며 조정 비용도 저렴합니다. 30초짜리 이름 변경은 낮은 노력이면 되고, 모듈 리팩터링은 높은 노력이 필요합니다.

다이얼을 기분이 아니라 작업에 맞추십시오. 작업→모델+노력 표는 탭 6의 모델 선택 섹션을 보십시오.

슬래시 명령

슬래시 명령은 모델이 아니라 Codex 자체를 제어합니다(모델 전환, 컨텍스트 비우기, 상태 보기). 메시지의 첫 글자가 /일 때만 작동합니다. /를 입력해 현재 진입점에서 사용 가능한 명령을 보십시오.

일상 CLI 명령, 하는 일별로 묶음:

⚠️ CLI는 40개 이상의 슬래시 명령을 노출합니다; 데스크톱 앱은 약 6개, IDE는 약 8개입니다. GUI 표면에서 CLI의 전체 목록을 기대하지 마십시오.

계획 모드와 프롬프팅

먼저 계획하고, 그다음 실행하십시오. 사소하지 않은 일이라면 목표를 설명하고 Codex가 계획을 만들게 하십시오; 계획을 검토한 뒤 실행하게 하십시오. 단계별 레시피가 아니라 목표와 제약을 주십시오 — 순서를 정하는 것은 에이전트 루프가 당신보다 낫습니다.

프롬프팅 원칙:

• 말을 늘리지 말고 컨텍스트를 주십시오. 파일을 가리키고, 목표를 말하고, 제약을 나열하십시오. 장황함은 도움되지 않고, 구체성이 도움이 됩니다.
• 하지 말아야 할 것을 말하십시오 — 부정 지시(“legacy/는 건드리지 마”, “npm 말고 pnpm 써”)가 긍정 지시보다 날카롭습니다.
• 메시지당 한 작업 — 에이전트 루프는 집중에 보상하고, 멀티태스킹 프롬프트는 희석시킵니다.

일반적인 워크플로

네 가지 일상 흐름:

AGENTS.md

AGENTS.md는 Codex의 프로젝트별 지시 파일입니다 — 매 실행 시작에, 행동하기 전에 읽습니다. Claude Code의 CLAUDE.md에 해당합니다(같은 개념, 다른 이름과 탐색 규칙).

왜 존재하는가: 매 실행은 백지 상태에서 시작합니다. AGENTS.md가 없으면 “pnpm 써, legacy/는 건드리지 마, 테스트는 이렇게 돌려”를 매번 다시 설명해야 합니다.

탐색 체인 (3 계층, 가까운 쪽이 이김):

1. 전역 — ~/.codex/AGENTS.md (또는 AGENTS.override.md, 이쪽이 이김). 프로젝트 간 기본값.
2. 프로젝트 루트 — Git 루트의 AGENTS.md. 팀 공유 규칙.
3. 하위 디렉터리 — 루트에서 현재 디렉터리까지 걸어 내려가며, 각 디렉터리가 AGENTS.md를 기여할 수 있습니다. 충돌 시 작업 디렉터리에 가장 가까운 쪽이 이깁니다.

~/.codex/AGENTS.md          ← global defaults (your preferences)
project-root/AGENTS.md      ← team rules (overrides global on conflict)
project-root/src/AGENTS.md  ← subdirectory rules (closest wins)

💡 충돌은 “가까운 쪽 우선”으로 해결 — 프로젝트 규칙이 개인 선호를 덮고, 하위 디렉터리 규칙이 프로젝트 규칙을 덮습니다. 이는 여러분이 원하는 팀 협업 동작 그 자체입니다.

효과적인 AGENTS.md 작성

가장 효과적인 활용: 피드백 루프로 취급하십시오. Codex가 코드베이스에 대해 잘못된 가정을 할 때, 채팅에서 고치는 것(일회성)으로 끝내지 말고 — 수정 사항을 AGENTS.md에 쓰게 하십시오. 몇 주 지나면 파일이 이미 잡아낸 함정들로 채워지고, 새 세션은 같은 오류를 반복하지 않게 됩니다.

config.toml 기초

config.toml은 동작 노브 파일입니다 — 에이전트가 글자 그대로 실행하는 머신 설정으로, AGENTS.md(자연어 안내)와 다릅니다. 자동차에 비유하자면: AGENTS.md는 소유자 설명서, config.toml은 대시보드 노브입니다.

두 위치:

⚠️ 신뢰 게이트: 프로젝트 수준의 .codex/config.toml은 신뢰되지 않은 프로젝트에서는 무시됩니다. 악의적으로 복제된 저장소가 자기 자신에게 조용히 권한을 부여하는 것을 막습니다. 프로젝트 설정이 “적용되지 않는다면” 처음 열 때 프로젝트를 신뢰했는지 확인하십시오.

최소 설정:

# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

config.toml 고급

파일 편집 없이 실행마다 덮어쓰기:

codex -c model="gpt-5.5" -c approval_policy="never"

프로필로 사전 설정된 구성 사이를 전환하십시오:

codex --profile ci        # loads the [profiles.ci] block

workspace-write 안에서 네트워크를 활성화하십시오 (기본값은 꺼져 있음 — 흔한 함정):

[sandbox_workspace_write]
network_access = true

설정 레퍼런스

빈번하게 쓰는 키들:

ℹ️ 전체 레퍼런스: developers.openai.com/codex/config-reference.

권한과 승인 정책

위의 두 노브로 구성합니다. 일상 개발에서는 초기 설정 후 거의 건드리지 않습니다 — workspace-write + on-request가 대부분의 작업을 덮습니다. 신뢰할 수 있고 컨테이너화된 자동화에만 never로 열고, 분석 목적으로 저장소를 Codex에 맡길 때만 read-only로 잠그십시오.

샌드박스와 승인

샌드박스는 파일시스템 쓰기를 작업공간으로 격리하고 네트워크 송신을 제어합니다. 핵심 동작:

• workspace-write에서 .git은 읽기 전용으로 보호됩니다 — Codex가 저장소 메타데이터를 망가뜨리지 않습니다.
• 쓰기가 허용되더라도 네트워크는 기본값으로 꺼져 있습니다 — 명시적으로 켜야 합니다.
• danger-full-access는 모든 경계를 제거합니다 — 컨테이너/VM 전용입니다.

⚠️ Windows 경고 (확인됨, 반드시 전달): Windows에서 Full Access 모드가 사용자 파일을 삭제한 보고가 여럿 있습니다 (240–700 GB 손실 보고). Windows에서 Full Access를 절대 활성화하지 마십시오; WSL2를 사용하고 workspace-write에 머무르십시오.

훅 (라이프사이클)

관리자는 requirements.toml로 훅을 잠글 수 있습니다:

allow_managed_hooks_only = true

이것은 관리형 훅은 허용하면서 사용자/프로젝트/세션 훅 설정을 무시합니다. requirements.toml에서 만 효과가 있습니다 — config.toml에 넣으면 아무 일도 일어나지 않습니다. 엔터프라이즈 거버넌스에 사용하십시오 (탭 6 참고).

MCP — 외부 도구

**MCP (Model Context Protocol)**는 Codex가 외부 도구를 호출하게 합니다 — 실시간 문서 가져오기, 데이터베이스 질의, 브라우저 구동. Codex는 정확히 두 가지 전송 유형을 지원합니다:

서버 추가 두 가지 방법:

# CLI (fastest) — context7 = free dev-docs server
codex mcp add context7 -- npx -y @upstash/context7-mcp

또는 config.toml에 직접 작성:

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

모델이 외부 도구 호출을 어떻게 결정하는가

💡 모든 MCP 설정은 config.toml에 있습니다 — --scope는 없습니다. 범위는 어떤 파일을 편집하느냐로 결정됩니다 (~/.codex/ = 전역, <repo>/.codex/ = 프로젝트, 신뢰 필요). CLI와 IDE가 이 하나의 설정을 공유합니다.

서브에이전트

**서브에이전트(subagent)**는 자체 스레드, 모델, 지시, 권한을 가진 전문 에이전트입니다. Codex는 여러 개를 병렬로 실행하며 각각은 메인 스레드에 요약만 반환합니다 — 시끄러운 중간 출력을 메인 컨텍스트에서 빼냅니다.

메인 에이전트가 작업을 분배하고, 서브에이전트는 원시 출력이 아닌 요약을 반환

서브에이전트가 푸는 두 가지 문제:

• 컨텍스트 오염 — 큰 작업 하나의 로그가 메인 스레드를 넘쳐나게 합니다; 서브에이전트가 어지러움을 격리합니다.
• 컨텍스트 부패 — 긴 스레드는 저하됩니다; 쪼개면 각 컨텍스트가 짧고 집중됩니다.

⚠️ 직관에 반대: Codex는 서브에이전트를 자동으로 생성하지 않습니다. 명시적으로 요청할 때만 분배합니다. 요청하지 않으면 병렬 처리를 기대하지 마십시오 — 비용 폭주를 막습니다.

커스텀 에이전트를 ~/.codex/agents/ 또는 <repo>/.codex/agents/의 TOML 파일로 정의하십시오:

# ~/.codex/agents/reviewer.toml
name = "reviewer"
model = "gpt-5.5"
instructions = "Review diffs for correctness bugs and security issues."

에이전트 스킬

**스킬(Skill)**은 SKILL.md 파일(및 선택적 스크립트/리소스)을 가진 디렉터리로 패키징된 재사용 가능한 워크플로입니다. 워크플로를 한 번 작성하면; Codex가 필요할 때 호출합니다.

스킬: SKILL.md와 선택적 스크립트, 참조 자료를 가진 디렉터리

최소 SKILL.md:

---
name: summarize-diff
description: Summarize uncommitted changes and flag risks. Use when the user asks for a change summary.
---

Summarize the diff, group changes by file, and call out anything risky
(uncommitted secrets, large deletions, test coverage gaps).

⚠️ 흔한 함정 (오래된 튜토리얼에서): 프론트매터는 **name + description**이 필요합니다 — trigger 필드는 없습니다. 트리거는 키워드가 아니라 description에 대한 의미 매칭으로 이루어집니다. 그리고 디렉터리는 ~/.codex/skills가 아닌 .agents/skills 아래입니다. 오래된 블로그 글이 아니라 공식 문서를 따르십시오.

점진적 로딩: 시작 시 Codex는 각 스킬의 이름, 설명, 경로만 로드합니다. 전체 SKILL.md는 스킬이 사용될 때만 로드됩니다 — 컨텍스트를 가볍게 유지합니다.

플러그인

**플러그인(plugin)**은 한 번의 설치로 능력 묶음입니다 — 스킬 + 에이전트 + 훅 + MCP 서버 — 각 조각을 손수 구성하는 대신 전체 설정을 한 번에 설치하도록 패키징됩니다. 커뮤니티나 팀이 이미 일관된 툴킷을 조립해 둔 경우 플러그인을 사용하고, 딱 하나만 필요할 때는 개별 스킬/MCP를 사용하십시오.

규칙과 훅

**규칙(Rules)**과 **훅(hooks)**은 실행 검문점과 트리거를 추가합니다:

• 규칙 — 컨텍스트에 따라 로드되는 조건부 지시(예: 프레임워크별 규칙).
• 훅 — 라이프사이클 이벤트(도구 사용 전, 턴 후 등)에서 발화하는 셸 명령으로 결정론적 자동화(저장 시 포맷, 명령 차단, 알림)에 씁니다.

훅은 config.toml이나 에이전트별로 정의할 수 있습니다; 엔터프라이즈는 관리형 전용으로 잠글 수 있습니다 (위의 allow_managed_hooks_only 참고).

Command → Agent → Skill 모델

Codex의 오케스트레이션은 Claude Code의 3계층 모델을 반영합니다:

확장 유형 선택

하네스가 중요한 이유

출력 품질 = f(유효 컨텍스트, 모델 능력, 반복 루프)

하네스 — AGENTS.md, config, 승인 정책, 스킬, 훅 — 가 유효 컨텍스트와 반복 품질을 형성합니다. 프롬프트만으로는 복제할 수 없습니다: 프롬프트는 권고에 불과하지만, 하네스는 도구 제한을 강제하고, 경로별로 규칙을 지연 로드하고, 병렬 서브에이전트를 스케줄하고, 세션에 걸쳐 상태를 유지합니다.

프롬프트가 닿지 못하는 계층 — 하네스가 여러분을 위해 하는 일

비대화형 모드 (codex exec)

codex exec는 TUI 없이 Codex를 실행합니다 — 프롬프트를 주면, 작업하고, 결과를 출력하고, 종료합니다. “사람 없는(human in the loop 없음)” 시나리오를 위해 만들어졌습니다: 스크립트, cron 잡, CI 파이프라인.

codex exec "Summarize this repo's structure and list 5 areas to watch"

핵심 설계 — 진행은 stderr로, 결과는 stdout으로. 이 분리 덕분에 깨끗한 결과를 다음 프로그램으로 파이프하면서도 화면에서 진행을 볼 수 있습니다:

# machine-readable event stream
codex exec --json "find flaky tests" | jq ...

# save just the final message to a file
codex exec -o result.txt "write release notes for last 10 commits"

⚠️ 비대화형 모드는 기본적으로 read-only 샌드박스입니다. 파일을 편집하게 하려면 샌드박스를 명시적으로 올리고(-s workspace-write), 승인도 올리십시오(완전 무인은 -a never).

실행 정책

codex exec는 **실행 정책(execution policy)**으로 통제할 수 있습니다 — 무인으로 허용된 행동에 대한 규칙 기반 제어입니다. 어떤 명령이 실행될 수 있는지, 어떤 경로가 쓰일 수 있는지 등을 제한하는 규칙을 정의하십시오. 안전한 CI 사용에 필수입니다.

Git과 GitHub 연동

Codex는 두 트랙으로 Git/GitHub와 연동합니다:

클라우드 리뷰는 유료 플랜 + 저장소를 Codex 클라우드에 인가해야 합니다; 로컬 /review는 그 어느 것도 필요 없습니다.

리뷰 규칙을 커스터마이즈하려면 AGENTS.md의 Review guidelines 섹션을 사용하십시오 — 예: “모든 라우트에 인증 미들웨어가 있어야 함”, “로그에 PII 없음”. 그러면 Codex가 일반적인 기준이 아니라 여러분의 기준으로 위반을 표시합니다.

GitHub Actions / CI

openai/codex-action은 GitHub 호스티드 러너에서 Codex를 실행하며, 저장소 이벤트(PR 열림, CI 실패)로 트리거됩니다. CI/CD 트랙입니다 — 데스크톱 앱의 로컬 Automations와 다릅니다.

최소 워크플로:

# .github/workflows/codex-review.yml
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: openai/codex-action@v1
        with:
          prompt-file: .codex/prompts/review.md
          sandbox: workspace-write

💡 두 자동화 트랙, 섞지 마십시오: GitHub Action(클라우드 러너, 저장소 이벤트, 팀 협업) vs 데스크톱 앱 Automation(여러분의 머신, cron 스케줄, 개인 작업). 작업이 있는 곳에 트랙을 맞추십시오.

Worktree — 병렬 격리

worktree는 각 Codex 스레드에 저장소 파일의 격리된 복사본(.git 메타데이터 공유)을 줍니다. 여러 작업이 서로 덮어쓰지 않고 병렬로 실행되게 합니다.

git worktree add ../feature-x -b feature-x
cd ../feature-x && codex    # isolated work on feature-x

• 같은 브랜치는 두 worktree에 동시에 체크아웃할 수 없습니다.
• Worktree + Handoff(데스크톱 앱)가 작업을 포그라운드/백그라운드 사이로 옮깁니다 — 예: 백그라운드 worktree에서 긴 리팩터링을 시작하는 동안 앞에서 계속 코딩.
• 오래된 worktree는 주기적으로 정리하십시오 — 각각이 전체 파일 복사본을 갖습니다.

Automations

데스크톱 앱의 Automations는 여러분의 머신에서 예약된 백그라운드 작업을 실행합니다 — “매일 아침, 어제의 커밋 요약”. CI(GitHub 러너)와 다릅니다 — 이들은 머신이 켜져 있는 동안만 실행됩니다. 각 예약 작업을 격리하려면 worktree와 짝지으십시오.

Computer Use

Computer Use는 Codex에게 “손”을 줍니다 — 화면을 보고, UI를 클릭하고, 브라우저를 구동할 수 있습니다. 범위: GUI 자동화, 브라우저 테스트, 데스크톱 앱 조작. 위험이 높습니다 — 보이는 모든 것에 행동할 수 있습니다; workspace-write나 컨테이너로 한정하고, 처음 몇 번의 실행은 밀접히 지켜보십시오.

연동 (Slack / Linear / SDK)

CLI 외에도 Codex는 Slack과 Linear에서 호출될 수 있고, SDK로 여러분의 제품에 내장될 수 있습니다. 이것들로 Codex를 별도의 목적지가 아니라 기존 워크플로의 한 노드로 만드십시오 — 예: Slack 메시지가 Codex 작업을 트리거하고, 결과가 채널에 다시 게시.

메모리 시스템

Codex의 메모리는 하나가 아니라 두 시스템입니다:

⚠️ 두 가지 흔한 실수: (1) 메모리가 실시간이라고 가정 — 세션이 한가해진 뒤에 쓰여지므로, 즉시 테스트하면 실패합니다; (2) 메모리가 AGENTS.md를 대체한다고 가정 — 그렇지 않습니다. “항상 적용” 규칙은 AGENTS.md에 두십시오; 절대 메모리에 걸지 마십시오.

Chronicle은 화면 콘텐츠로 공급되는 실험적이고 Codex 전용 메모리입니다 (Pro + macOS 전용, EU/UK/스위스 제외). 활성화 전 프라이버시 함의를 검토하십시오.

보안과 위험 경계

“Codex가 이것을 만지게 해도 될까”를 위한 의사결정 프레임워크:

⚠️ 타협 불가 항목: 실제 머신에서 절대 --yolo 하지 말 것; Windows에서 절대 Full Access 하지 말 것; 신뢰할 수 없는 복제 저장소의 .codex/는 신뢰 불가로 취급할 것 (Codex가 기본적으로 그렇게 합니다 — 덮어쓰지 마십시오).

엔터프라이즈와 거버넌스

회사 전반에 Codex를 운영하는 것(1인 대비)에는 거버넌스가 필요합니다:

• 관리형 설정 — 사용자가 완화할 수 없는 IT 배포 조직 설정.
• requirements.toml — allow_managed_hooks_only = true가 훅을 관리형 전용으로 잠급니다.
• 신뢰 정책 — 어떤 프로젝트의 .codex/ 계층이 로드되는지 통제.
• 허용 목록(Allowlist) — MCP 서버, 도구, 모델을 승인된 집합으로 제한.

가격과 서드파티 모델

결제는 ChatGPT 구독(Pro/Plus/Team/Enterprise — 사용량 포함) 또는 API 크레딧(토큰당 지불) 중 하나입니다. 현재 가격은 OpenAI 사이트에서 확인하십시오 — 숫자는 변동됩니다; “기준일”과 함께 인용하십시오.

서드파티 모델: config.toml의 model_provider로 Codex를 다른 제공자(예: DeepSeek, 로컬 모델)로 라우팅하십시오. 비용 통제, 데이터 거주, 오프라인 사용에 유용합니다.

Windows 참고 사항과 문제 해결

Windows: WSL2 안에서 실행하십시오 (네이티브는 미지원). Full Access 데이터 손실 보고는 Windows 특정입니다 — workspace-write에 머무르십시오.

흔한 실패:

Claude Code에서 마이그레이션

여러분의 Claude Code 멘탈 모델은 약 90% 이전됩니다. 개념 매핑:

에이전트 루프, “행동하기 전에 읽기”, “단계가 아니라 목표 주기” 습관은 그대로 이전됩니다.

명령과 설정 치트 시트

# install / auth
curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex login                      # ChatGPT OAuth
printenv OPENAI_API_KEY | codex login --with-api-key
codex doctor                     # self-check

# daily CLI
codex                            # interactive
codex exec "..."                 # non-interactive
codex -s workspace-write -a on-request

# slash commands (in-session)
/init  /model  /effort  /status  /clear  /compact  /diff  /review  /mcp  /skills  /agents  /memories

# config.toml essentials
model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true

모범 사례와 FAQ

상투적 표현을 넘어, 실제로 통하는 것:

• 피드백 루프로서의 AGENTS.md — Codex가 하는 모든 잘못된 가정이 한 줄이 됩니다.
• 작업에 모델이 아니라 노력을 맞추기 — /effort가 더 저렴하고 더 영향력이 큽니다.
• 스레드당 한 작업 — 컨텍스트 부패는 현실입니다; 작업을 쌓지 마십시오.
• 품질이 떨어지기 전에 압축하기, 뒤가 아니라.
• --yolo는 컨테이너화 — 실제 머신에서는 절대.

FAQ (요약):

• Codex가 세션에 걸쳐 기억하나요? AGENTS.md(신뢰 가능)와 Memories(최선 노력)에 있는 것만.
• OpenAI 외 모델을 쓸 수 있나요? 네, config의 model_provider로 가능합니다.
• 파일 편집을 맡겨도 안전한가요? workspace-write + on-request에서는 네 — 프로젝트를 벗어나기 전에 멈춥니다.
• CLI vs 데스크톱 앱? CLI가 상위 집합입니다; 먼저 배우십시오.

용어집