Codex CLI /goal 사용방법 : 목표를 기억하고 스스로 이어가는 자율 루프 - /goal과 Ralph Loop 비교

안녕하세요! 갓대희 입니다.

 

/goal은 Codex CLI 신규버전 (0.128.0 : 2026-04-30) 업데이트의 핵심 기능 중 하나는 슬래시 커맨드 이다. 목표를 한 번 입력해 두면, AI가 할 일이 없어지는 순간마다 "계속 진행해"라는 신호를 스스로 받아 작업을 이어가는 구조다.

 

한국 개발자 사이에서도 반응이 빠르게 갈렸다. 어떤 사람은 "드디어 ralph loop가 Codex CLI에 들어왔다"고 환영했고, 어떤 사람은 "장시간 돌아가는 자율 모드가 비용 폭탄 아니냐"고 걱정했다. 마침 OpenAI의 Felipe Coury가 원문 트윗에서 "Our take on the Ralph loop"라고 표현하기도 했으니, 두 진영 모두 어느 정도 일리가 있다.

목차

1. /goal — 자율 루프 한 줄 요약
2. 설정 — config.toml 한 줄과 명시적 활성화
3. /goal 사용법 — 네 개의 명령어로 끝나는 인터페이스
4. 내부 동작 — 모델 툴, continuation 템플릿, 안전장치
5. Claude ralph loop와의 비교 — 같은 철학, 다른 구조
6. 토큰 소모 후 동작 — 확인된 것과 확인되지 않은 것
7. 실전 활용 팁
8. 결정 매트릭스 — 언제 쓰고, 언제 쓰지 않는가
9. 마무리

이 글 한 줄 요약

Codex CLI 0.128.0에 새로 추가된 /goal 기능의 소스코드 기반 동작 분석, Claude oh-my-claudecode ralph loop와의 비교, 안전한 실전 운용 가이드를 담는다.

 

1. /goal — 자율 루프 한 줄 요약

한 줄로 정리하면, /goal은 "대화 세션이 끊겨도 목표는 사라지지 않고, 모델이 쉬고 있는 틈마다 '계속 진행해' 신호를 받아 작업을 이어가는 루프"다. 여기서 핵심은 목표가 대화를 넘어 유지된다는 점이다. 다음 턴에 사용자 입력이 없으면 시스템이 알아서 모델을 다시 깨워 작업을 이어가게 한다.

 

2. 설정 — config.toml 한 줄과 명시적 활성화

/goal은 기본으로 켜져 있는 기능이 아니다.

 - 나의 경우도 /goal 을 그냥 사용해보려고 했는데 동작하지 않았다.

 

0.128.0 버전 기준으로 OpenAI의 기능 성숙도 구분 상 Experimental(실험적)보다도 앞 단계인 UnderDevelopment(개발 중)로 분류되어 있다. Codex의 features 모듈 소스를 보면 다음과 같이 나온다.

FeatureSpec {
    id: Feature::Goals,
    key: "goals",
    stage: Stage::UnderDevelopment,
    default_enabled: false,
}

default_enabled: false가 의도적으로 들어가 있다.

공식 Feature Maturity 문서는 Under development를 "아직 사용할 준비가 안 된" 단계로 설명한다.

 

즉, "공개 실험 기능"이 아니라 코드와 릴리즈 노트가 먼저 들어간 개발 중인 기능으로 보는 게 맞다.

/goal 기능을 킬려면 공식 config 가이드에 나오는 [features] 섹션에 한 줄 추가하면 된다.

 

config.toml에 다음 내용을 추가하면 된다.

[features]
goals = true

 

ex) 활성화 후 /goal 확인

 

3. /goal 사용법 — 네 개의 명령어로 끝나는 인터페이스

사용자 인터페이스는 의외로 단순하다.

slash_dispatch.rs의 GOAL_USAGE 상수가 사실상 모든 사용법을 압축해서 보여 준다.

const GOAL_USAGE: &str = "Usage: /goal <objective>";
const GOAL_USAGE_HINT: &str = "Example: /goal improve benchmark coverage";

match trimmed.to_ascii_lowercase().as_str() {
    "clear"  => Some(GoalControlCommand::Clear),
    "pause"  => Some(GoalControlCommand::SetStatus(AppThreadGoalStatus::Paused)),
    "resume" => Some(GoalControlCommand::SetStatus(AppThreadGoalStatus::Active)),
    _ => None,
}

정리하면 네 개의 형태가 있다.

명령	동작
/goal <목표>	새 목표를 생성하고 자율 루프를 시작한다
/goal pause	현재 활성 목표를 paused 상태로 전환한다
/goal resume	paused 목표를 active로 되돌린다
/goal clear	현재 목표를 제거한다

인자 없이 빈 /goal 만 실행하면 현재 목표 상태를 표시하는데, 목표가 설정되어 있으면 내용을 보여주고 없으면 No goal is currently set. 라고 출력한다.

요약하자면, /goal은 "새 목표 입력 + 라이프사이클 제어 3종"으로 디자인되어 있고, 사용자가 외울 단어는 pause/resume/clear 세 개뿐이다.

검증 메모: 0.128.0의 TUI /goal <objective> 경로는 objective 문자열만 넘긴다. token_budget 필드는 코어와 모델 툴에는 존재하지만, 이 슬래시 커맨드에 별도 예산 인자 문법이 노출된 것은 확인되지 않는다.
따라서 예산 이야기는 "지원되는 표면에서는 가능"으로 표현해야 한다.

 

4. 내부 동작 — 모델 툴, continuation 템플릿, 안전장치

표면 인터페이스는 단순하지만, 내부에는 모델 자율성과 사용자 통제를 분리한 설계가 깔려 있다. 핵심 구성 요소는 세 가지다.

/goal 런타임 흐름 한눈에 보기

1. 사용자가 목표 설정
/goal <objective>

→

2. Thread goal 저장
active / paused / complete

→

3. idle 조건 확인
진행 중 턴, 대기 입력, plan mode 제외

→

4. continuation 주입
목표, 시간, 토큰 사용량 포함

→

5. 다음 행동 실행
완료 시 모델이 complete 처리

연속 continuation에서 tool call이 없으면 다음 자동 continuation은 억제된다. 토큰 예산이 있는 목표가 한도에 닿으면 새 작업 대신 wrap-up 지시가 들어간다.

 

4-1. 모델에게 노출되는 세 개의 툴

goal_tool.rs를 보면 모델이 사용할 수 있는 goal 관련 함수는 정확히 세 개로 제한된다.

pub const GET_GOAL_TOOL_NAME: &str = "get_goal";
pub const CREATE_GOAL_TOOL_NAME: &str = "create_goal";
pub const UPDATE_GOAL_TOOL_NAME: &str = "update_goal";

모델은 get_goal로 현재 목표를 조회하고, create_goal로 새 목표를 만들며, update_goal로 상태를 갱신한다. 다만 update_goal의 description에는 다음과 같은 제한이 명시되어 있다.

Set status to complete only when the objective has actually been achieved and no required work remains. You cannot use this tool to pause, resume, or budget-limit a goal; those status changes are controlled by the user or system.

(번역) 목표가 실제로 달성되어 남은 필수 작업이 없을 때만 complete로 상태를 변경하라.
이 툴로 목표를 pause·resume·budget-limit 할 수 없으며, 해당 상태 변경은 사용자 또는 시스템만 제어한다.

 

즉, 모델이 직접 손댈 수 있는 상태는 complete 하나뿐이고, pause/resume/budget_limited는 사람 또는 런타임만 제어한다. 자율성과 통제권을 명확히 분리한 설계로 보인다.

 

또한 create_goal의 description은 다음 두 가지를 못 박아 둔다.

첫째, 사용자나 system/developer 지시에서 명시적으로 요청했을 때만 목표를 만든다. 일반 태스크에서 모델이 임의로 목표를 추론해 만드는 것은 금지된다.

둘째, 이미 목표가 있으면 create_goal은 실패하고, 상태 변경은 update_goal로만 처리해야 한다. "조용히 자율 모드로 진입하는" 가능성을 의도적으로 차단한 것이다.

 

4-2. continuation 프롬프트 템플릿

루프를 실제로 굴리는 건 continuation.md 템플릿이다. 모델이 한 턴을 끝내고 아무 입력도 없는 대기 상태(idle)가 되면, 시스템이 이 템플릿 내용을 모델에게 다시 전달한다.

Continue working toward the active thread goal. Budget: - Time spent pursuing goal: {{ time_used_seconds }} seconds - Tokens used: {{ tokens_used }} - Token budget: {{ token_budget }} - Tokens remaining: {{ remaining_tokens }} ... Avoid repeating work that is already done. Choose the next concrete action toward the objective.

(번역)

활성 목표를 향해 계속 작업하라.

예산 현황: - 목표 추진에 사용한 시간: {{ time_used_seconds }}초 - 사용한 토큰: {{ tokens_used }} - 토큰 예산: {{ token_budget }} - 남은 토큰: {{ remaining_tokens }} ...

이미 완료된 작업을 반복하지 마라. 목표를 향한 다음 구체적인 행동을 선택하라.

단순한 "계속해" 한 마디가 아니다. 토큰을 얼마나 썼는지, 시간이 얼마나 지났는지까지 함께 전달해서, 모델이 자기 진행 상황을 파악한 채로 다음 행동을 고르게 만든다.

 

4-3. 안전장치 — idle 우선순위와 무한 루프 차단

루프가 무한정 돌지는 않는다. core/src/goals.rs를 보면 두 가지 제동 규칙이 있다.

• 이어가기(continuation)는 세션이 완전히 비어 있을 때만 시작된다. 사용자 입력이 들어오거나 처리할 메시지가 남아 있으면 뒤로 밀린다.
• 연속된 이어가기에서 실제 도구 호출(tool call)이 한 번도 없으면 그 다음 이어가기는 자동으로 막힌다.

 

두 번째 규칙이 무한 루프 방지 장치다. 모델이 아무것도 하지 않고 빈 답만 반복하면 더 이상 깨우지 않는다는 뜻이다. 또한 작업이 중간에 끊기면(인터럽트) 목표가 자동으로 일시정지(paused) 상태가 되고, 작업을 다시 이어가면 자동으로 활성 상태로 돌아온다.

 

목표의 상태는 goal_status.rs 기준으로 active(진행 중), paused(일시정지), budget_limited(예산 소진), complete(완료) 네 가지로 관리된다. 터미널 화면 상단에는 경과 시간이나 토큰 사용량이 표시된다.

토큰 예산을 따로 지정하지 않아도 자율 실행 자체는 가능한데, 이때는 경과 시간만 보인다. 같은 파일의 테스트가 그 동작을 직접 보여 준다.

fn active_goal_usage_reports_time_without_budget() {
    assert_eq!(active_goal_usage(None, 12_500, 120), Some("2m".to_string()));
}

fn active_goal_usage_prefers_token_budget() {
    assert_eq!(active_goal_usage(Some(50_000), 12_500, 90), Some("12.5K / 50K".to_string()));
}

토큰 예산이 주어지면 화면에 12.5K / 50K 같은 잔량으로 표시되고, 없으면 경과 시간만 나온다. 내부 로직은 예산 관리를 지원하지만, 터미널에서 /goal 목표내용으로 직접 입력할 때는 예산값을 함께 넣는 문법이 확인되지 않는다. 예산 설정이 필요하다면 서버 API나 모델 툴을 통한 경로를 확인해야 한다.

 

5. Claude ralph loop와의 비교 — 같은 철학, 다른 구조

앞서 인용한 OpenAI 발표 트윗이 ralph loop를 직접 언급한 만큼, Claude Code 진영의 oh-my-claudecode ralph 스킬과 비교해 두는 편이 자연스럽다. ralph 스킬 SKILL.md는 다음과 같이 자기 정의한다.

Ralph is a PRD-driven persistence loop that keeps working on a task until ALL user stories in prd.json have passes: true and are reviewer-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, structured story tracking, and mandatory verification before completion.

(번역)

ralph는 PRD 기반 지속 루프로, prd.json의 모든 요구사항 항목이 passes: true 상태가 되고 검토자가 검증할 때까지 계속 작업한다.

ultrawork의 병렬 실행을 세션 지속, 실패 시 자동 재시도, 구조화된 항목 추적, 완료 전 필수 검증으로 감싼 구조다.

 

이 정의가 두 도구의 차이를 잘 보여준다. Codex /goal은 자유 텍스트 목표 하나를 AI가 알아서 풀어가는 구조다.

반면 ralph는 기획 문서(PRD/prd.json)에 적힌 요구사항 항목들을 하나씩 구현하고, 각 항목을 검증자가 확인한 뒤에야 다음으로 넘어가는 다단계 구조다. 같은 SKILL.md에서 단계 설명을 보면 ralph 흐름이 더 분명해진다.

Steps: 1. PRD Setup ... 2. Pick next story ... 3. Implement ... 4. Verify the current story's acceptance criteria ... 7. Reviewer verification (tiered, against acceptance criteria) ... 8. On approval: run /oh-my-claudecode:cancel to cleanly exit

(번역) 단계: 1. PRD 설정 ... 2. 다음 항목 선택 ... 3. 구현 ... 4. 현재 항목의 완료 조건 검증 ... 7. 검토자 검증(단계적, 완료 조건 기준) ... 8. 승인 시: /oh-my-claudecode:cancel로 깔끔하게 종료

 

ralph는 architect 같은 별도 검토자(reviewer) 단계를 구조상 강제로 포함한다. 재미있는 건 ralph가 옵션으로 Codex CLI를 검토자로 불러 쓸 수 있다는 점이다.

If --critic=codex, run omc ask codex --agent-prompt critic "..." for the approval pass. The Codex critic prompt MUST include: 1. The full list of acceptance criteria from prd.json ... 2. A directive to evaluate whether the implementation is OPTIMAL — oh-my-claudecode ralph SKILL.md (같은 출처)

(번역) --critic=codex인 경우, 승인 단계에서 omc ask codex --agent-prompt critic "..."을 실행하라. Codex critic 프롬프트에는 반드시 다음이 포함되어야 한다: 1. prd.json의 전체 완료 조건 목록 ... 2. 구현이 최적인지 평가하는 지시문

 

다시 말해, 두 도구는 경쟁만 하는 관계가 아니라 보완재로 묶일 수 있다.

Claude는 PRD 기반 분해/검증 루프를 돌리고, 그 검증 단계에 Codex CLI를 critic으로 호출하는 식이다.

비교 축	Codex /goal	oh-my-claudecode ralph
트리거 방식	슬래시 커맨드 /goal <목표>	슬래시 커맨드 /oh-my-claudecode:ralph
목표 표현	자유 텍스트 목표 하나	prd.json의 요구사항 항목 여러 개
종료 조건	모델이 update_goal로 complete 처리	모든 story passes: true + reviewer 승인
사람 개입 지점	pause/resume/clear 사용자 제어, 모델은 complete만	각 요구사항 항목별 완료 확인 + 검토자(architect/critic) 단계
토큰/비용 관리	내부 로직은 토큰 예산 관리 지원. 다만 터미널 /goal 입력에서 예산 인자 문법은 미확인	별도 명시 없음. critic 호출 시 별도 비용
생태계	OpenAI Codex CLI 0.128.0+	Claude Code + oh-my-claudecode 플러그인

한 줄로 요약하면, /goal은 모델 자율성을 최대화하는 단일 루프이고, ralph는 PRD라는 외부 아티팩트로 자율성을 강제 분해하는 다단계 루프다.

 

 

ex) AI에게 goal 예시를할만한 프롬프트를 생성해달라고 했더니 엄청 장황하게 작성해 주었는데, 이대로 진행해보겠다.

  /goal 이 Next.js 앱의 공개 서비스/라우트 메타데이터를 하나의 타입 안전한 레지스트리로 단일화해줘.

  목표:
  현재 Hub 카드, Header/Footer 링크, sitemap 생성, 라우트 관련 테스트에 흩어져 있는 공개 페이지/서비스 정보를 하나의 typed registry로 정리
  하고, 중복 하드코딩을 줄여줘.

  범위:
  - src/constants, src/app/sitemap.ts, src/components/features/hub, src/components/layout/Header*, Footer를 먼저 조사한다.
  - public route/service 정보를 표현하는 작은 typed registry를 설계한다.
  - registry에는 필요에 따라 path, title, description, category, priority, sitemap 설정, nav 노출 여부, hub 노출 여부, asset/icon 메타데이
  터 같은 필드를 포함한다.
  - sitemap.ts와 Hub 카드, Header/Footer 링크 등 중복이 큰 부분은 registry를 사용하도록 리팩터링한다.
  - 기존 라우트, SEO 동작, 화면 UI는 가능한 한 유지한다.
  - 명백한 불일치나 버그가 있으면 작은 범위에서 함께 고친다.
  - 중요한 공개 라우트가 누락되지 않는지, 중복 path가 없는지, sitemap/hub/nav 메타데이터가 일관적인지 검증하는 테스트를 추가하거나 보강한
  다.

  제약:
  - 새 의존성은 추가하지 않는다.
  - diff는 작고 리뷰 가능하게 유지한다.
  - 기존 라우트와 SEO 동작을 깨지 않는다.
  - 관련 없는 UI 개편은 하지 않는다.
  - 이 프로젝트의 기존 패턴, path alias, TypeScript strict 모드를 따른다.

  검증:
  - lint, unit test, 관련 E2E test를 실행한다.
  - 가능하면 pnpm quality-gate까지 실행한다.
  - 전체 quality gate가 기존의 무관한 실패 때문에 실패하면, 어떤 명령이 어떤 이유로 실패했는지 증거와 함께 분리해서 보고한다.
  - registry 구현, 중복 제거, 테스트 보강, 남은 리스크 정리가 끝났을 때만 완료 처리한다.

  최종 보고:
  - 어떤 중복 소스를 발견했는지
  - 어떤 registry 구조를 선택했는지
  - 어떤 파일이 단순해졌는지
  - 어떤 테스트를 추가/수정했는지
  - 전후로 어떤 유지보수 리스크가 줄었는지

 

ex)

  - 이후 얼마나 오래 일하는지, 어떤 결과가 얼마만에 나오게 되는지 살펴보자.

 - 생각보다 빨리 완료 되었다. (나중엔 좀더 복잡한 개발 요청을 해보도록 하겠다.)

 - 15m 소요시간 확인.

 

 

6. 토큰 소모 후 동작 — 확인된 것과 확인되지 않은 것

"며칠씩 돌아가다 토큰이 떨어지면 어떻게 되느냐"는 질문이 가장 많이 나온다. 이 부분은 사실과 추정을 분리해서 적는다.

Codex 0.128.0의 goals/budget_limit.md 템플릿에는 다음 본문이 들어 있다.

The active thread goal has reached its token budget. The system has marked the goal as budget_limited, so do not start new substantive work for this goal. Wrap up this turn soon: summarize useful progress, identify remaining work or blockers, and leave the user with a clear next step. Do not call update_goal unless the goal is actually complete.

(번역) 활성 목표가 토큰 예산 한도에 도달했습니다.

시스템이 목표를 budget_limited로 표시했으므로, 이 목표로 새로운 실질적인 작업을 시작하지 마세요.

이번 턴을 곧 마무리하세요: 유용한 진행 상황을 요약하고, 남은 작업이나 장애물을 파악하고, 사용자에게 명확한 다음 단계를 남겨 주세요.

목표가 실제로 완료된 경우가 아니라면 update_goal을 호출하지 마세요.

이 템플릿에서 확인할 수 있는 사실은 두 가지다.

첫째, 토큰 예산이 소진되면 시스템이 목표를 budget_limited(예산 소진) 상태로 표시한다.

둘째, 진행 중인 턴을 강제로 끊지 않고 "마무리 지시"를 주입한다.

즉, 진행하던 작업을 요약하고 다음 단계를 남겨 놓은 뒤 조용히 멈추는 방식이다.

PR #18076에서도 같은 동작을 "soft stop"이라고 표현한다.

주의: budget_limited 이후 자동 재시작 메커니즘은 소스코드와 릴리즈 노트에서 확인되지 않는다.

커뮤니티 일각의 "토큰 충전 후 알아서 다시 돈다" 류 표현은 직접 검증이 어렵다.

확인할 수 있었던 범위에서는, 재시작은 사용자가 /goal resume을 입력하거나 새 목표를 다시 등록해야만 일어난다.

자동 재시작 로직이 어딘가 숨어 있을 가능성을 단정적으로 부정할 수는 없지만, 적어도 0.128.0 시점의 공개 코드와 문서로는 그 동작을 보장하지 못한다.

 

7 활용 팁

소스코드 분석을 바탕으로 실제 운용 시 유용한 가이드를 정리한다.

7-1. 목표 작성 요령

소스코드의 create_goal 설명에는 "일반 작업 중에 멋대로 목표를 추론하지 마라"고 못 박혀 있다.

이 원칙은 목표를 작성하는 사람에게도 그대로 적용된다. 목표 텍스트에 다음 세 가지가 명확하게 들어가야 한다.

• 완료 정의: 어떤 상태가 되면 update_goal이 complete로 호출되어야 하는지 명시한다. "벤치마크 커버리지를 70%로 올린다"처럼 정량 기준이 들어가면 모델이 종료를 판단할 단서가 생긴다.
• 금지 행동: 무인 모드에서 절대 하면 안 되는 행동을 함께 적는다. 예컨대 "프로덕션 DB에 직접 쿼리하지 않는다", "GitHub PR 머지는 사람이 한다"처럼 단단한 가드레일을 텍스트에 박는다.
• 시간/예산 한도: 토큰 예산 설정을 지원하는 API나 툴을 쓰는 경우라면 예산을 명시한다. 터미널 화면에서 /goal 목표내용으로만 입력하는 경우에는 예산 문법이 확인되지 않으므로, 목표를 작게 나누고 수동으로 pause/clear 지점을 만든다.

 

7-2. 안전한 실행 환경

/goal을 켜기 전에는 환경 자체를 격리한다. 다음 항목은 자율 루프 본격 운용 전에 한 번씩 점검해 둔다.

• 격리 환경 우선: 별도 작업 디렉토리(worktree), 컨테이너, VM에서 실행한다. 이어가기(continuation)는 대기 상태마다 자동으로 켜지므로 같은 환경에서 다른 작업을 병행하지 않는다.
• Git 보호 설정: 루프가 스스로 PR을 만드는 워크플로라면, main 같은 보호된 브랜치에 직접 push하지 못하도록 권한을 분리해 둔다.
• /goal pause 위치 미리 파악: 터미널 화면에서 즉시 멈추는 방법을 미리 익혀 둔다. "이 방향이 아니다" 싶을 때 pause를 입력하면 이어가기가 멈춘다.
• 예산 설정 방법 확인: 무인 실행에는 예산 상한이 있는 게 안전하다. 단, 터미널 슬래시 커맨드만으로는 토큰 예산 설정 문법이 확인되지 않으니, 서버 API나 모델 툴 경유 여부를 먼저 확인한다. 그게 어렵다면 목표를 잘게 나눠 수동 중단 지점을 만드는 게 현실적이다.
• 로그 분리: 이어가기는 사람이 없는 시간대에도 돌 수 있다. 로그를 별도 파일이나 채널로 빼 두고, 나중에 어떤 동작이 있었는지 추적할 수 있게 한다.

정리하면, 자율 모드의 비용은 모델이 결정하지만 안전은 사람이 사전 설계한다.

 

8. 결정 매트릭스 — 언제 쓰고, 언제 쓰지 않는가

상황	권장 도구
단일 자유 텍스트 목표를 모델 자율로 풀고 싶다	Codex /goal
요구사항을 항목별로 분해하고 검토자 승인이 필요하다	oh-my-claudecode ralph
Codex 환경에서 token 예산만으로 자연 종료를 원한다	token_budget을 노출하는 app-server/API 경로. 단순 TUI /goal만으로는 확인 필요
Claude Code 환경이고 PRD 기반 검증이 익숙하다	oh-my-claudecode ralph
자율 모드를 처음 써 보는 단계라 위험을 최소화하고 싶다	둘 다 신중히. 특히 /goal은 격리 환경 + 작은 목표 단위 + 가능한 경우 token_budget

결정 원칙은 둘 중 하나를 고르는 게임이 아니라 자율성과 가드레일의 비율을 어디서 잡을지 정하는 문제다.

 

9. 마무리

/goal은 화려한 신기능이라기보다, 커뮤니티가 비공식으로 써 오던 ralph loop 방식을 OpenAI가 자기 식으로 정리한 버전에 가깝다. config 한 줄, 슬래시 커맨드 네 개, 모델용 툴 세 개, 이어가기 템플릿 한 장이라는 단순한 구성이다. 그 안에서 AI가 자율로 할 수 있는 범위와 사람이 통제하는 범위를 명확히 나눈 점은 인상적이다.

---

참고 자료

• Codex CLI v0.128.0 Release Notes
• openai/codex GitHub Repository
• codex-rs/features/src/lib.rs (Goals 피처 정의, rust-v0.128.0)
• codex-rs/tui/src/chatwidget/slash_dispatch.rs (/goal 명령 분기, rust-v0.128.0)
• codex-rs/tools/src/goal_tool.rs (모델 툴 정의, rust-v0.128.0)
• codex-rs/core/templates/goals/continuation.md (rust-v0.128.0)
• codex-rs/core/templates/goals/budget_limit.md (rust-v0.128.0)
• Codex config-basic 가이드
• Codex Feature Maturity 가이드
• TestingCatalog: OpenAI updates Codex and prepares remote control feature
• HN: How Ralph Wiggum went from The Simpsons to the biggest name in AI right now (#46524652)
• oh-my-claudecode ralph SKILL.md