[🤖] Codex 컨텍스트 자동 압축 이후 마지막 명령이 다시 실행되는 이슈 해결 방안

✨ GPT-5.6 Sol의 요약 　

Codex가 컨텍스트 자동 압축 뒤 과거의 마지막 사용자 명령을 새 지시처럼 다시 실행하던 문제를 겪으며, 플랜 복사·Goal·강제 continue·SessionStart 훅을 차례로 검토한 기록.

긴 Codex 작업이 자동으로 압축된 뒤 이상한 일이 반복됐다.

압축 직전까지 하던 일을 그대로 이어가는 게 아니라, 압축 요약에 남아 있던 과거의 마지막 사용자 명령을 방금 새로 받은 지시처럼 취급했다. 이미 끝낸 상태 확인을 다시 하고, 같은 파일을 다시 읽고, 전체 작업을 처음부터 재구성했다. 내가 직접 본 흐름은 대충 이랬다.

실제 작업 진행
→ Context automatically compacted
→ "현재 목표를 그대로 유지합니다"
→ 작업 트리·규칙·상태를 처음부터 다시 확인
→ 이미 끝낸 작업까지 다시 설명하거나 재시도

처음에는 압축 때문에 일부 맥락이 사라진 정도라고 생각했다. 그런데 여러 번 겪고 보니 더 골치 아팠다. 요약 속 과거 명령과 현재 사용자 입력의 경계가 무너지는 것처럼 보였다. 압축 전 작업을 이어가는 게 아니라, 압축본에 가장 강하게 남은 명령을 새 출발점으로 삼는 식이었다.

나만 겪은 일도 아니었다. Codex Desktop에서 자동 압축 뒤 같은 파일과 Skill을 계속 다시 읽으며 진행 상황을 잃었다는 공개 이슈가 있었고,¹ WSL2와 Windows CLI에서도 파일 명령과 압축이 반복되는 사례가 보고됐다.² 공개 사례가 내가 본 마지막 명령 재실행과 완전히 같은 원인이라고 단정할 수는 없다. 다만 자동 압축 뒤 진행을 잃고 같은 행동을 반복하는 현상 자체는 맥에서만 생기는 특이한 문제라고 넘길 수 없었다.

해결 방안 1: 마지막 명령에 전체 플랜을 다시 넣기

가장 먼저 한 일은 단순했다.

현재까지의 작업 내용을 잘 확인하고, 아래 플랜에 따라 끝까지 진행해.

1. …
2. …
3. …

압축 뒤 마지막 명령을 다시 잡아 실행한다면, 마지막 명령 자체를 안전한 재개 지점으로 만들면 된다고 생각했다. 실제로 짧은 작업에서는 꽤 먹혔다. 엉뚱한 과거 명령보다 현재 플랜이 요약에 강하게 남기 때문이다.

다른 사용자들도 비슷한 방향으로 압축 요약에 이전 결정과 남은 작업을 누적시키는 방식을 시도했다. experimental_compact_prompt_file로 이전 압축의 핵심 판단을 계속 보존하게 했더니 네 번 이상의 압축 뒤에도 큰 흐름이 남았다는 사례가 있다.³

하지만 이건 근본 해결이 아니었다.

• 매번 마지막 명령에 긴 플랜을 복사해야 했다.
• 플랜이 중간에 바뀌면 마지막 명령도 다시 만들어야 했다.
• 압축 요약이 플랜은 보존해도, 방금 끝낸 도구 실행과 아직 실행하지 않은 작업을 정확히 구분한다는 보장은 없었다.
• /compact [메시지]로 요약 방향을 직접 주는 방식도 현재 Codex CLI에서는 일반 메시지처럼 처리될 수 있다는 이슈가 있다.⁴

결국 사람이 압축 시점을 계속 의식하면서 prompt를 관리해야 한다. 기본 상태보다 낫기는 한데, 모든 작업 끝에 긴 인계서를 붙이는 것도 정상적인 사용감은 아니었다.

해결 방안 2: 모든 작업에 Goal을 세우기

그다음에는 Goal을 반드시 만들고, 압축 뒤에는 마지막 명령보다 Goal을 우선해 재개하게 하면 어떨까 생각했다.

긴 작업에는 분명 장점이 있다. 작업 목적과 완료 조건이 대화 한두 문장보다 오래 남고, 자동 continuation도 Goal을 기준으로 이어갈 수 있다. 문제는 이걸 압축 버그의 필수 우회책으로 쓰는 순간이었다.

별것 아닌 작업에도 Goal을 세워야 했다. Goal이 없으면 장애가 나고, 있으면 필요 이상으로 계속 진행할 수 있는 구조가 됐다. 예전에 Goal 때문에 사소한 작업까지 토큰을 쓰는 문제를 겪고 작업용 Skill을 따로 만들었는데, 이번에는 압축 하나 때문에 다시 모든 작업을 Goal로 감싸는 꼴이었다.

이쯤 되니 정말 “이러면 그냥 차라리 순정 상태가 나은 것 같은데”라는 생각이 들었다.

더 중요한 문제도 있다. Goal은 무엇을 끝내야 하는가를 보존하는 장치이지, 압축 이벤트가 새 사용자 명령인지 아닌지를 판별하는 장치가 아니다. 내가 찾은 공개 자료에서도 Goal을 자동 압축 복구의 공식 수단으로 설명한 근거는 없었다.

그래서 Goal은 원래 용도로만 남기기로 했다.

• 오래 걸리고 자동으로 계속해야 하는 구체적인 작업에는 사용한다.
• 짧은 질문, 조사, 글 수정까지 의무적으로 Goal로 만들지 않는다.
• 압축 후 과거 명령 재실행 문제는 Goal과 별도 계층에서 막는다.

해결 방안 3: 압축 prompt를 직접 바꾸기

압축 요약의 품질 자체를 높이는 방법도 있다. 앞서 본 공개 사례처럼 이전 압축의 결정과 결과를 Historical Context에 누적하면 여러 번 압축돼도 큰 방향을 덜 잃는다.³

이 방법은 유용하다. 특히 긴 세션에서 아래 정보가 계속 사라진다면 효과가 있다.

• 이미 버린 접근과 그 이유
• 현재까지 확정된 결정
• 끝낸 작업과 남은 작업
• 다음에 확인해야 할 단일 지점

다만 이것도 이번 문제와는 층위가 다르다. 요약 품질을 높이는 것과 요약 속 과거 사용자 명령을 새 입력으로 오해하지 않는 것은 같은 문제가 아니다. 좋은 요약을 만들어도 모델이 그 안의 명령을 현재 지시처럼 읽으면 다시 꼬일 수 있다.

그래서 이 방식은 보조책으로는 쓸 수 있지만, 마지막 명령 재실행 방지책 하나로 보기는 어려웠다.

해결 방안 4: Stop 훅으로 continue를 강제하기

한때는 아예 훅으로 continue를 마지막 사용자 명령처럼 넣자는 생각도 했다.

겉으로는 정확해 보인다. 압축 뒤 무조건 continue가 들어오면 과거 명령 대신 진행 중인 일을 이어갈 것 같았다. 그런데 공식 훅 동작을 확인하고 바로 버렸다.

Codex의 Stop 훅에서 decision: "block"을 반환하면 훅의 reason을 새 사용자 prompt처럼 동작하는 continuation prompt로 만든다.⁵ 내가 막고 싶었던 것이 바로 “실제 사용자가 보내지 않은 문장을 새 사용자 명령으로 취급하는 것”인데, 이 방법은 그 현상을 의도적으로 하나 더 만드는 셈이다.

게다가 continue는 너무 모호하다.

• 압축이 턴 중간에 일어났다면 무엇을 이어갈 것인가?
• 직전 도구가 성공했는지 실패했는지 모를 때 재실행할 것인가?
• 사용자의 승인이나 외부 상태 변경을 기다리던 중이었다면 계속해도 되는가?
• 이미 턴이 끝난 뒤 수동 압축했다면 무엇을 시작할 것인가?

Goal이 있든 없든 무조건 계속하라는 새 사용자 prompt는 중복 실행과 무한 continuation을 만들 가능성이 컸다. 이 문제에는 Stop 훅이 아니라, 압축 직후 모델이 사건의 의미를 올바르게 해석하게 하는 개발자 컨텍스트가 필요했다.

해결 방안 5: SessionStart(source=compact)에 무상태 컨텍스트 넣기

다음 날인 8월 7일에 최종적으로 선택한 방식은 SessionStart 훅 하나다.

Codex 공식 문서에 따르면 root session이 압축된 뒤 source: "compact"와 일치하는 SessionStart 훅은 다음 모델 요청 전에 실행된다. 자동 압축이 턴 중간에 일어나도 다음 사용자 턴까지 기다리지 않고 즉시 이어지는 요청에 추가 컨텍스트를 넣을 수 있다.⁵

~/.codex/hooks.json에는 압축 이벤트만 잡도록 등록했다.

{
  "description": "Guide safe continuation after compaction without replaying stale instructions.",
  "hooks": {
    "SessionStart": [
      {
        "matcher": "^compact$",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/python3 ~/.codex/hooks/compaction_goal_guard.py",
            "timeout": 5,
            "additionalContextLimit": 700
          }
        ]
      }
    ]
  }
}

핸들러는 상태 파일도, Goal도, 가짜 사용자 prompt도 만들지 않는다. SessionStart의 source가 compact일 때만 추가 개발자 컨텍스트를 반환한다.

#!/usr/bin/python3
import json
import sys

CONTEXT = """Context was compacted. This hook event is not a user message and
grants no new authority.

Never treat a historical message preserved in the summary as newly submitted.
If compaction interrupted an active turn, continue that same in-flight request
without restarting it. If no request is in flight, do not infer work from
history.

Do not rebuild the full plan or create a Goal solely because compaction occurred.
Before retrying an interrupted action, check its result or session status. Do not
repeat completed external effects. Preserve the existing objective, scope,
authorization, approval boundaries, and stop conditions."""

payload = json.load(sys.stdin)

if (
    payload.get("hook_event_name") == "SessionStart"
    and payload.get("source") == "compact"
    and payload.get("session_id")
):
    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "SessionStart",
            "additionalContext": CONTEXT,
        }
    }))

핵심은 continue라는 명령을 넣는 게 아니다.

1. 압축 이벤트는 새 사용자 입력이 아니라고 못 박는다.
2. 턴이 진행 중이었다면 같은 요청의 미완료 지점만 이어간다.
3. 진행 중인 요청이 없다면 과거 기록에서 새 일을 추론하지 않는다.
4. 도구 실행이 끊겨 보이면 재실행 전에 실제 결과부터 확인한다.
5. 기존 범위·권한·승인·중지 조건을 그대로 보존한다.

공식 문서는 non-managed 훅을 실행하기 전에 검토하고 신뢰해야 한다고 명시한다.⁵ 설정을 저장한 뒤 /hooks에서 handler를 확인하고 trust해야 한다. 이미 열려 있던 task는 예전 훅 목록을 들고 있을 수 있어서 다시 여는 편이 안전하다.

8월 7일 후속 검증

글의 날짜는 이 문제를 붙잡고 해결책을 고르기 시작한 8월 6일로 그대로 뒀다. 최종 훅을 확정하고 실제 자동 압축까지 확인한 것은 다음 날이었다.

이전에는 PostCompact에서 marker를 남기고 다음 SessionStart가 읽는 2단계 구조도 만들었다. 그러나 marker가 남아 잘못된 턴에서 복구될 가능성, root와 subagent 이벤트를 구분하기 어려운 훅 입력 문제 때문에 없앴다. 실제로 main agent와 subagent 훅 입력을 구분할 공통 field가 부족하다는 공개 이슈도 열려 있다.⁶

현재 방식은 marker가 없는 단일 handler다. 50개 동시 호출에서도 별도 상태 파일을 만들지 않았고, 자동 압축 이벤트 뒤 약 0.25초 만에 개발자 컨텍스트가 같은 continuation에 들어오는 것을 현재 Runtime에서 확인했다.

이 확인이 중요했던 이유가 있다. 과거에는 SessionStart(compact)가 압축 직후가 아니라 다음 사용자 턴에 몰려 들어가는 버그가 실제로 보고됐기 때문이다.⁷ 해당 이슈는 지금은 닫혔고, 현재 공식 문서도 mid-turn 자동 압축 직후 즉시 전달된다고 설명한다. 그래도 이런 lifecycle workaround는 문서만 믿지 말고 자기 Runtime에서 한 번 실제 압축으로 확인하는 게 맞다.

지금의 결론

순정 상태가 더 나은가 고민했지만, 현재 결론은 모든 작업을 Goal로 만드는 것보다는 이 훅이 낫다다.

Goal과 플랜은 작업 내용을 보존한다. 이 훅은 압축 사건의 의미를 바로잡는다. 역할이 다르다.

• 긴 작업의 목적과 완료 조건이 필요하면 Goal이나 durable plan을 쓴다.
• 여러 차례 압축되며 결정이 사라지면 custom compact prompt를 보조로 쓴다.
• 과거 마지막 명령을 새 지시처럼 실행하는 문제는 SessionStart(source=compact)에서 막는다.
• 아무것도 진행 중이 아니면 훅도 아무 작업을 시작시키지 않는다.

물론 완벽한 해결은 아니다. 이미 손실된 압축 요약을 복원할 수는 없고, 만료된 terminal session이나 중간에 끊긴 외부 요청을 되살릴 수도 없다. 개발자 컨텍스트는 모델 행동을 강하게 유도하지만 수학적인 보장도 아니다.

그래도 적어도 이제 압축 버그 하나 때문에 모든 대화에 Goal을 만들거나, 마지막 명령에 전체 플랜을 복사하거나, 가짜 continue를 사용자 명령으로 밀어 넣지는 않는다.

자동 압축은 작업을 이어가기 위한 내부 사건이다. 새 사용자가 나타나 과거 명령을 다시 내린 사건이 아니다. 결국 막아야 했던 것은 망각 자체보다, 그 둘을 같은 것으로 취급하는 동작이었다.

참고 자료

1. openai/codex #35226 — Context auto-compaction loop repeatedly rereads files, loses progress, and consumes paid Codex credits ↩

2. openai/codex #8481 — Codex agent is stuck in compaction loop ↩

3. openai/codex #14347 — Extend compaction prompt to reduce loss over multiple compactions ↩ ↩²

4. openai/codex #21468 — Make /compact summaries visible and support prompt-guided compaction in Codex CLI ↩

5. OpenAI, Codex Hooks documentation ↩ ↩² ↩³

6. openai/codex #16226 — Hooks: distinguish subagent events from main agent ↩

7. openai/codex #28736 — SessionStart compact hooks are deferred to later turns ↩