스레드 라이프사이클

핵심 요약

스레드 핵심 흐름은 start(목표/검증 기준 고정)·resume(승인/입력 대기 확인)·fork(대안 분기)·steer(진행 중 개입)·archive/delete/close(보존 정책 결정 후 종료)입니다.
resume는 단순 대화 복원이 아니라 pending approval·pending input까지 복원하므로, 재개 시 가장 먼저 "맥락이 이어졌는가"가 아니라 "무엇 때문에 멈췄는가"를 확인합니다.
steering은 탐색 범위 축소·우선순위 변경·목표 축소처럼 진행 중 방향 조정에 쓰고, 요구사항이 완전히 바뀌거나 결과를 비교해야 하면 fork가 더 안전합니다.
0.128.0+ /goal은 하루 이상 이어질 작업에만 붙여 결과물과 멈춰야 할 조건을 함께 적고, 0.132.0부터 usage limit·반복 blocker에서 무한히 토큰을 태우지 않고 멈춥니다.
0.136.0 /archive는 세션을 resume/fork 대상에서 보호하는 운영 신호이며, app-server 클라이언트는 turn 상태·queued follow-up·pending approval·resume 복원 상태를 UI/로그에 노출해야 합니다.
0.140.0 /delete는 current transcript와 spawned descendant session을 영구 삭제하므로 archive와 별도 정책으로 다루고, 0.142.0 /usage는 장기 goal·delegation 전에 token budget을 확인하는 진입점입니다.

Codex를 깊게 쓰기 시작하면 프롬프트보다 더 중요한 것이 스레드 관리입니다. 최근 릴리스는 thread/start, thread/resume, fork, steering, approval 복원 흐름을 계속 다듬어 왔습니다.

왜 중요한가

장시간 작업을 중단/재개할 때 맥락 유실을 줄여줍니다
멀티에이전트와 Cloud Tasks를 하나의 운영 모델로 묶을 수 있습니다
승인 대기, 추가 입력, 모델 전환 상태를 추적하기 쉬워집니다

핵심 흐름

단계	의미	운영 포인트
`start`	새 작업 시작	작업 목표/검증 기준을 명확히 고정
`resume`	기존 작업 재개	approval/input 대기 상태가 살아있는지 확인
`fork`	대안 접근 분기	위험한 실험이나 비교 검토에 적합
`steer`	진행 중 turn 개입	장시간 작업 범위를 줄이거나 우선순위 조정
`archive/delete/close`	종료	결과 요약, 보존/삭제 정책, descendant session 영향 확인

재오픈 스레드 상태 복원 (0.114.0)

0.114.0 이전에는, 작업 도중 세션을 강제 종료(Ctrl+C 등)한 뒤 스레드를 다시 열면 in-progress 상태에 갇혀 resume이 불가능한 문제가 있었습니다.

0.114.0에서 이 버그를 고쳐, 중간에 종료된 스레드를 다시 열면 올바른 상태(pending 또는 idle)로 자동 복원됩니다. 장시간 멀티에이전트 작업 도중 예기치 않게 종료돼도 스레드를 안전하게 이어갈 수 있습니다.

Handoff transcript 컨텍스트 (0.114.0)

에이전트 간 handoff 때 실시간 transcript 컨텍스트가 함께 넘어갑니다. 예전에는 handoff를 받은 에이전트가 역할과 지시만 받았지만, 이제는 직전까지의 대화 맥락도 함께 넘겨받아 연속성이 크게 좋아졌습니다.

덕분에 resume/fork/steer 시나리오에서도 “이전에 무슨 이야기가 오갔는지”를 에이전트가 스스로 파악하니, 사람이 반복해서 설명할 일이 줄어듭니다.

Realtime 세션 컨텍스트 개선 (0.116.0)

0.116.0에서 Realtime 세션이 최근 스레드 컨텍스트를 안고 시작하도록 바뀌었습니다. 예전에는 실시간 세션이 빈 상태로 시작됐지만, 이제는 직전 대화 맥락을 자동으로 넘겨받아 연속성이 좋아집니다. 오디오 재생 중 자기중단(self-interruption) 빈도도 줄어 실시간 음성 워크플로우가 한결 안정됐습니다.

원격 resume/fork 대화 히스토리 복원 (0.116.0)

원격 환경에서 resume나 fork를 할 때 대화 히스토리가 제대로 복원되지 않던 문제를 고쳤습니다. 이제 원격 세션에서도 이전 대화 내용이 정확히 이어지니, Cloud Tasks나 원격 연결 기반 워크플로우에서 스레드 재개가 더 안정적입니다.

`/resume` 직접 점프 + picker 안정화 (0.119.0)

0.119.0부터 /resume은 TUI에서 session ID나 이름으로 바로 점프할 수 있습니다. 목록을 스크롤해 고르는 방식보다 다루기 편해져, 병렬 세션이 많은 팀에서 특히 쓸모 있습니다.

같은 릴리즈에서 resume picker도 함께 다졌습니다.

false empty state가 번쩍이며 나타나는 문제 완화
thread 이름과 timestamp 라벨 신선도 개선
zero-token 종료 뒤 resume 힌트 보존
현재 스레드를 다시 resume할 때의 크래시 회피

이제 resume은 "중단된 세션 복원"을 넘어 큰 세션 카탈로그를 빠르게 훑는 진입점에 더 가깝습니다.

Realtime V2 백그라운드 진행률 스트리밍 (0.120.0)

0.120.0에서 Realtime V2는 백그라운드 에이전트 진행률을 작업 중간에도 스트리밍하고, active response가 끝나기 전에 follow-up response를 큐잉할 수 있게 됐습니다.

thread lifecycle 관점에서 중요한 변화입니다.

사용자는 "멈춘 것처럼 보이는 긴 작업"과 "실제로 진행 중인 작업"을 더 쉽게 구분할 수 있음
후속 입력이 즉시 처리되지 않더라도 queue 상태를 전제로 운영할 수 있음
guardian/approval/workflow UI는 running, queued, follow-up pending 상태를 구분해 노출하는 편이 좋아짐

queued slash command와 side 질문 (0.121.0~0.122.0)

0.121.0~0.122.0에서는 "작업이 도는 동안 사람이 어떻게 개입하느냐"가 더 좋아졌습니다.

composer가 Ctrl+R reverse search를 지원해, 장시간 세션에서도 이전 지시를 빠르게 재사용할 수 있음
accepted slash command가 로컬에서 다시 recall되어 반복 운영 명령을 덜 다시 타이핑하게 됨
0.122.0부터 queued input이 slash command와 ! shell prompt를 받아, 실행 중인 작업을 끊지 않고도 보조 지시를 넣을 수 있음
/side가 공식 slash commands 문서에 등재되어, 부모 thread를 보존한 짧은 보조 질문을 표준 운영 명령으로 다룰 수 있음

이제 thread lifecycle은 resume/fork/steer만이 아니라 running thread에 안전하게 끼어드는 UX까지 넣어서 봐야 합니다.

persisted `/goal`과 큰 thread pagination (0.128.0~0.132.0)

0.128.0부터는 장시간 작업에 **지속 목표(goal)**를 붙이는 흐름이 들어왔습니다. /goal <objective>로 목표를 설정하고, /goal pause, /goal resume, /goal clear로 실행 중인 목표를 다룹니다.

운영할 때는 goal을 "프롬프트 한 줄"이 아니라 thread metadata처럼 다루는 편이 좋습니다.

큰 migration, 정리 작업, 반복 검증처럼 하루 이상 이어질 수 있는 작업에만 goal을 붙임
goal에는 결과물과 중단 조건을 함께 적음
pause 상태로 resume된 thread를 다시 열 때는 /goal로 현재 goal을 먼저 확인
사람이 범위를 바꾸면 기존 goal을 수정하기보다 clear 후 새 goal로 시작

0.130.0에서는 app-server client가 큰 thread를 unloaded, summary, full turn item view로 page 처리할 수 있어, 장기 작업을 "전체 transcript 로드"가 아니라 "요약·필요 turn 중심 탐색"으로 다루기 쉬워졌습니다. goal과 pagination을 함께 쓰면 긴 thread를 무작정 compact하기보다 목표·요약·필요 turn만 남기는 식으로 운영할 수 있습니다.

0.132.0에서는 goal continuation이 usage limit이나 반복 blocker에 걸렸을 때 무한히 이어가며 토큰을 태우지 않고 멈추도록 보강됐습니다. 팀 runbook에는 goal을 설정할 때 "완료 조건"뿐 아니라 "멈춰야 할 조건"도 함께 적어두세요.

Archive / Unarchive 운영 (0.136.0)

0.136.0부터 세션은 TUI의 /archive나 CLI의 codex archive / codex unarchive로 보관 상태를 바꿀 수 있습니다. Archived session은 복원하기 전까지 resume/fork 대상에서 보호되니, 단순히 목록을 숨기는 기능이 아니라 "이 작업은 더 이상 이어서 수정하지 않는다"는 운영 신호로 쓰는 편이 좋습니다.

권장 기준:

완료된 조사, 폐기한 실험, 오래된 재현 세션은 archive로 정리
보류 중 approval/input이 있는 세션은 archive하기 전에 결과와 blocker를 남김
다시 이어야 할 작업은 unarchive 후 /status, /goal, /diff를 먼저 확인
내부 app-server 클라이언트는 thread/archived, thread/unarchived 이벤트를 로그와 UI에 노출

앱에서는 archived chats/threads가 Settings의 archived section에 나타나고, unarchive하면 원래 위치로 돌아옵니다. 세션을 많이 다루는 운영자라면 archive 상태를 검색·필터 조건으로 삼으세요.

Delete / Import / Usage 운영 (0.140.0~0.142.0)

0.140.0부터 /delete와 codex delete <SESSION>은 current transcript와 spawned descendant session을 영구 삭제합니다. 민감 정보가 섞였거나 폐기해도 되는 실험 세션에만 쓰고, 완료된 조사·리뷰 기록은 기본적으로 /archive를 우선합니다.

0.140.0의 /import는 Claude Code setup, project files, recent chats를 Codex configuration/local files로 가져옵니다. import는 migration 보조 도구이므로, 직후 /diff, /debug-config, /status로 실제 변경과 적용 config를 확인한 뒤 커밋 여부를 결정하세요.

0.142.0의 /usage는 daily/weekly/cumulative token activity와 earned rate-limit reset을 확인합니다. 장기 /goal, scheduled reminder, multi-agent delegation을 시작하기 전에는 /usage weekly와 rollout token budget을 먼저 보고, earned reset은 고우선 재시도에만 사용합니다.

resume hinting + 대형 스레드 카탈로그 대응 (0.123.0~0.125.0)

0.123.0~0.125.0에서는 "어떤 스레드를 다시 열어야 하는지"와 "많은 스레드를 어떻게 탐색할지"가 더 좋아졌습니다.

current vs archived thread 구분: 0.123.0부터 resume hinting이 현재 스레드와 archived thread를 더 잘 구분합니다
heading-only lookup: plain #가 heading-only context lookup을 열어, 긴 문맥에서 필요한 지점을 더 빨리 찾을 수 있습니다
cursor-based pagination: 0.125.0에서 app-server thread/resume/fork가 cursor pagination을 지원해 1,000개 이상 task도 안정적으로 다룹니다
multi-environment persistence: thread에 여러 environment name이 더 안정적으로 유지되어, resume 후 환경 문맥이 덜 어긋납니다

이제 resume은 단순 복원 기능이 아니라 큰 task 카탈로그를 운영하는 탐색 레이어에 더 가깝습니다.

resume 전략

최근 릴리스에서 thread/resume은 단순 대화 복원이 아니라 pending approval과 pending input까지 함께 복원하는 쪽으로 바뀌었습니다. 그래서 재개할 때 가장 먼저 확인할 것은 “맥락이 이어졌는가”가 아니라 “무엇 때문에 멈췄는가”입니다.

재개 체크리스트

마지막 turn이 완료 상태인지 확인
승인 대기인지, 추가 입력 대기인지 분리
현재 모델/권한/작업 루트가 바뀌지 않았는지 확인
장시간 작업이면 steer 또는 fork가 더 적절한지 판단

steering을 언제 쓰나

steering은 새 프롬프트를 다시 쓰는 기능이 아니라 이미 진행 중인 작업의 방향을 조정하는 기능에 가깝습니다.

적합한 상황:

탐색 범위를 더 좁히고 싶을 때
우선순위를 바꾸고 싶을 때
“수정은 하지 말고 원인 분석만”처럼 목표를 축소할 때
승인 대기 이후 후속 지시를 짧게 넣고 싶을 때

부적합한 상황:

요구사항이 완전히 바뀌는 경우
결과물을 서로 비교해야 하는 경우
모델/권한 정책이 크게 달라지는 경우

이때는 steer보다 fork가 더 안전합니다.

fork 전략

fork는 “현재 컨텍스트를 유지한 채 다른 접근을 병렬 실험”하는 데 유리합니다.

예시:

한 스레드는 원인 분석
다른 스레드는 최소 수정안 작성
또 다른 스레드는 리스크/롤백 플랜 정리

최종적으로 부모 스레드에서 하나만 채택하면 됩니다.

멀티에이전트와의 관계

멀티에이전트는 thread lifecycle을 더 촘촘하게 씁니다.

부모 스레드: 목표/검증 기준 관리
자식 스레드: 역할별 실행
child-thread approval: 위험 작업에서 사람이 개입
resume/fork/steer: 장시간 병렬 작업을 통제하는 장치

멀티에이전트는 별도 기능이 아니라 스레드 라이프사이클을 병렬로 돌리는 운영 방식으로 보는 편이 정확합니다.

앱/클라이언트 구현 포인트

앱 서버를 붙이는 팀이라면 다음 항목을 UI/로그에 꼭 노출하는 편이 좋습니다.

현재 turn 상태
background agent progress / queued follow-up 여부
pending approval / pending input 여부
현재 모델과 reroute 여부
steer 개입 시점
resume 시 복원된 상태
archive/unarchive 상태와 복원 시점

이 정보를 숨기면 장시간 세션에서 “왜 멈췄는지”를 사람이 따라가기 어려워집니다.

참고 문서

Changelog: https://developers.openai.com/codex/changelog (영어)
Multi-agent: https://developers.openai.com/codex/multi-agent (영어)
Codex App: https://developers.openai.com/codex/app (영어)
GitHub Releases: https://github.com/openai/codex/releases (영어)