취소를 누른 뒤, 각 층은 어떻게 수습하는가

Codex에게 테스트 파일을 고치라고 해요. 모델이 먼저 cargo test를 돌리고, 컴파일러가 rustc 오류를 두 화면 쏟아내며 종료 코드는 1입니다. 다음 초에 대화가 멈추고 화면에 turn aborted가 떠요. 에이전트를 처음 만드는 사람이 자주 이렇게 합니다. 도구가 Err를 반환하면 라운드 전체가 같이 죽어요. 모델은 stderr를 보기도 전에 세션이 끝납니다.

분진은 도구가 대화로 돌아오는 그 문에서 일어나요. 문턱이 세 층입니다.

가장 얕은 층: 프로세스는 이미 돌았어요. 종료 코드가 0이 아니거나, 명령이 시간 초과되거나, 샌드박스가 거절해도 모두 도구 회신이 됩니다. success는 true예요. handler가 끝났고, 회신을 모델에 먹여도 된다는 뜻입니다. 명령이 성공했는지는 본문에 적혀 있어요.

출처: codex-rs/core/src/tools/context.rs 344–353행

중간 층: 호출 자체가 안 됐어요. 인자가 깨졌거나, 프로세스가 안 뜨거나, apply_patch 컨텍스트가 안 맞으면 RespondToModel로 갑니다. 이때만 회신 success가 false예요. 모델이 문장을 읽고 고쳐 다시 시도합니다.

가장 깊은 층: payload가 안 맞거나 태스크 join이 실패해야 Fatal을 쓰고 CodexErr로 올려 turn을 멈춥니다.

도구 층 자신의 열거형은 두 칸뿐입니다. RespondToModel은 문자열을 모델에 돌려줍니다. Fatal이어야 엔진 오류로 올라가요. Fatal이 아니면 기본으로 Ok로 접습니다. 대화를 멈추려면 Fatal이나 CodexErr를 써야 해요.

use thiserror::Error;

/// Error returned while executing a model-visible tool invocation.
#[derive(Debug, Error, PartialEq)]
pub enum FunctionCallError {
    #[error("{0}")]
    RespondToModel(String),
    #[error("Fatal error: {0}")]
    Fatal(String),
}

cargo test 종료 코드 1은 가장 얕은 층에서 멈추고, 오류 열거형의 문턱도 넘지 못해요. 샌드박스 거절도 Ok로 갑니다. 프록시가 요청을 막고 명령 프로세스에 HTTP 403을 돌려줘도 얕은 층에 머뭅니다. 모델 API의 403이어야 엔진 오류예요. 두 403을 한 칸으로 합치지 마세요.

출처: codex-rs/core/src/tools/handlers/unified_exec/exec_command.rs 384–411행; codex-rs/network-proxy/src/responses.rs 76–83행

handler의 IO 오류가 turn 루프까지 바로 올라오면 대화 라운드 전체가 같이 죽어요. 기본은 되먹임이고, 멈추려면 명시적으로 써야 합니다. 다른 언어로 다시 써도 이 선은 그대로예요. 내부 에이전트를 만든다면 이 칸부터 베끼세요. 도구 실패는 되먹이고, 엔진 실패여야 루프를 멈춥니다.

사용자가 Esc를 누르면 멈춰야 하는 건 지금 그 샘플링만이 아니에요. 샘플링은 아직 스트림을 읽고, 도구는 파일을 쓰는 중일 수 있고, 백그라운드 terminal은 이미 떠 있을 수 있습니다. 샘플링만 죽이면 도구는 디스크를 계속 고칩니다. 프로세스를 한칼에 전부 죽이면 unified exec의 백그라운드 작업도 잘못 죽어요.

태스크가 시작할 때 취소 토큰을 바로 만듭니다. 샘플 요청은 child_token()을 쓰고, 도구 디스패치가 한 번 더 child 해요. 부모 토큰이 취소되면 자식도 같이 취소됩니다. 자식이 스스로 취소해도 부모는 건드리지 않아요. 그게 취소 나무입니다.

출처: codex-rs/core/src/session/turn.rs 1399행; codex-rs/core/src/stream_events_utils.rs 319–324행

or_cancel은 누가 먼저 왔는지를 고정된 모양으로 씁니다. 어떤 future든 토큰 한 장과 짝을 이뤄요. 취소가 먼저 오면 CancelErr를 반환하고, 언제나 TurnAborted가 됩니다.

출처: codex-rs/async-utils/src/lib.rs 4–31행; codex-rs/protocol/src/error.rs 269–273행

사용자가 Esc를 누르면 프로토콜 입구는 Op::Interrupt예요. 계약은 고정입니다. 현재 태스크를 중지하고, 백그라운드 terminal은 죽이지 않아요. handle_task_abort는 먼저 cancel()한 뒤 100밀리초를 기다립니다. 시간 초과면 task.handle.abort()예요. 토큰이 먼저 신호를 내서 태스크가 스스로 마무리할 틈을 줍니다. 못 끝내면 그때 강제 중단하고, 그 한 칼은 되돌릴 수 없어요.

출처: codex-rs/protocol/src/protocol.rs 546–548행; codex-rs/core/src/tasks/mod.rs 66행, 880–913행

사용자 의도 하나, 여러 층이 각자 마무리합니다. 협력 취소에 단단한 기한을 더하는 건 동시성 시스템의 흔한 모양이에요. Python에서는 asyncio.Event만으로 최소판을 만들 수 있습니다. CodexErr 변형 37개를 베낄 필요는 없어요.

도구가 이미 파일을 고친 뒤에 취소가 오면, 히스토리는 어떻게 적을까요. 이미 끝난 출력을 aborted by user로 고쳐 쓰면, 다음 라운드 모델은 쓰기가 안 된 줄 알고 패치를 한 번 더 칠 수 있어요.

도구 future는 디스패치 결과와 토큰을 동시에 기다려요. 토큰이 먼저 와도 handler가 종말에 닿았는지를 봅니다. 이미 끝났으면 실제 결과를 남기고, 안 끝났을 때만 abort한 뒤 AbortedToolOutput을 만들며 본문은 aborted by user after Xs예요.

출처: codex-rs/core/src/tools/parallel.rs 177–206행, 243–260행

그다음 모델이 볼 수 있는 표시를 <turn_aborted> 안에 넣어 추가합니다. 문장은 두 가지를 인정해요. unified exec가 백그라운드에서 아직 돌 수 있고, 중지된 도구가 이미 일부를 실행했을 수 있다는 점입니다. 표시를 히스토리에 쓴 뒤 바로 flush_rollout()합니다. 어떤 클라이언트는 TurnAborted를 받으면 rollout을 다시 읽으므로, 표시는 먼저 디스크에 떨어져야 해요.

출처: codex-rs/core/src/context/turn_aborted.rs 1–35행; codex-rs/core/src/tasks/mod.rs 920–962행

히스토리는 추가만 하고 고쳐 쓰지 않아요. 중지는 뒤에 조각만 붙이고, 이미 디스크에 떨어진 도구 출력은 그대로입니다. 다음 라운드 모델은 끝난 출력, 중지된 도구의 회신, 중지 표시를 동시에 볼 수 있어요. 컨텍스트 규율의 첫 조항이 바로 이 모양입니다.

출처: AGENTS.md 91–100행