Codex CLI 내에서 에이전트가 다른 에이전트에게 보내는 메시지가 더 이상 로컬 히스토리(local history)에서 읽을 수 없는 상태로 남게 됩니다. 2026년 6월 5일에 병합된 PR #26210 이후부터, MultiAgentV2의 암호화가 에이전트 간 각 메시지의 평문(plain text) 필드를 비우고 그 자리에 암호화된 블롭(blob)만을 남깁니다.

openai/codex 리포지토리에서 2026년 6월 13일 사용자 ignatremizov가 제기한 issue #28058은 이로 인한 실질적인 결과를 기록하고 있습니다: 아무도 암호화를 해제하지 않고서는 상위 에이전트(parent agent)가 하위 에이전트(subagent)에게 어떤 작업을 위임했는지 나중에 읽을 수 없게 되었습니다.

TL;DR

• openai/codex 리포지토리(98,000개 이상의 스타와 14,600개의 포크 보유)의 issue #28058은 2026년 6월 13일 ignatremizov에 의해 오픈되었습니다.
• 원인은 2026년 6월 5일에 병합된 PR #26210, "Encrypt multi-agent v2 message payloads"입니다.
• MultiAgentV2가 활성화된 버전 0.137.0 이후의 빌드에 영향을 미칩니다.
• InterAgentCommunication의 content 필드가 비워지며, 실제 텍스트는 encrypted_content에만 존재합니다.
• spawn_agent, send_message, followup_task 호출에 영향을 줍니다.
• 암호화된 스키마를 검증할 때 400 에러를 보고하는 issue #26753과는 다르며, 이는 감사(auditing) 문제입니다.
• 제안된 해결책은 모델이 받는 페이로드(payload)와 분리된, 암호화되지 않은 감사(audit) 필드를 추가하는 것입니다.
• 이 글이 작성된 시점까지 해당 issue는 해결을 위한 풀 리퀘스트(pull request)가 연결되지 않은 채 오픈 상태로 남아 있습니다.

서론

서론

Codex CLI는 코드 에이전트(code agents)와 작업하기 위한 OpenAI의 명령줄 도구(command-line tool)입니다. 이 도구의 MultiAgentV2 기능은 하나의 부모 에이전트가 여러 하위 에이전트(sub-agents)에게 작업을 분배할 수 있게 합니다. 예를 들어, 한 에이전트는 테스트를 검토하고, 다른 에이전트는 모듈을 리팩터링(refactor)하며, 또 다른 에이전트는 버그를 조사합니다. 이 기능이 작동하기 위해 에이전트들은 세 가지 도구 호출(tool calls)을 사용하여 서로 메시지를 주고받습니다: spawn_agent (특정 작업과 함께 하위 에이전트 생성), send_message (추가적인 컨텍스트 전달), 그리고 followup_task (후속 작업 할당).

버전 0.137.0까지 이러한 메시지들은 로컬 히스토리(rollout) 내에 평문(plain text)으로 저장되었으며, 이를 통해 모든 개발자가 나중에 한 에이전트가 다른 에이전트에게 무엇을 요청했는지 검토할 수 있었습니다. PR #26210은 에이전트 간 메시지 전송에 대한 개인정보 보호 강화(privacy hardening)의 일환으로 이를 의도적으로 변경했습니다. issue #28058에 기록된 바에 따르면, 문제는 이 변경 사항이 모델을 위한 암호화(encryption)와 감사(audit)를 수행하는 인간이 읽을 수 있는 가독성(legibility)을 구분하지 않는다는 점입니다.

이 히스토리는 단순한 미적 요소가 아닙니다. 협업 환경에서 Codex CLI를 사용하는 팀들은 작업이 완료된 후 질문에 답하기 위해 rollout에 의존합니다. 즉, 한 에이전트가 다른 에이전트에게 무엇을 요청했는지, 어떤 순서로 진행되었는지, 그리고 결과가 원래의 작업에서 벗어나지는 않았는지 등을 확인해야 합니다. 이 정보원이 더 이상 읽을 수 없게 되면, 감사는 누군가가 원래의 프롬프트(prompt)를 다른 곳에 저장해 두었는지 여부에 의존하게 되는데, 이는 모든 워크플로우(workflow)에서 기본적으로 수행되는 작업이 아닙니다.

무엇이 발생했나

보고서는 그 메커니즘에 대해 정확하게 설명하고 있습니다. codex-rs/protocol/src/protocol.rs (fde21ba 커밋의 735~791행)에 정의된 InterAgentCommunication 구조체는 두 개의 관련 필드를 가집니다: 평문 텍스트인 content (String)와 선택 사항인 encrypted_content (Option<String>)입니다. 기존 생성자(constructor)인 new()는 content를 실제 텍스트로 채우고 encrypted_content는 None 상태로 둡니다.

새로운 생성자(constructor)인 new_encrypted()는 그 로직을 반대로 수행합니다. 즉, content를 빈 문자열로 초기화하고 메시지를 오직 encrypted_content에만 저장합니다. MultiAgentV2가 하위 에이전트(subagent)로의 전달(delivery)을 암호화할 때 new_encrypted()를 사용합니다. 그 결과, 로컬 히스토리(local history), 트레이스 감소(trace reduction), 그리고 부모 에이전트 측의 모든 디버깅 표면(debugging surface)에서 작업의 읽기 가능한 텍스트나 메시지를 잃게 됩니다.

이슈(issue) 작성자는 변경 사항 이후 롤아웃(rollout)을 조사해서는 더 이상 답변할 수 없게 된 세 가지 구체적인 질문으로 이를 요약합니다: spawn_agent 시 하위 에이전트가 어떤 작업을 받았는지, send_message로 어떤 메시지가 전송되었는지, 그리고 나중에 히스토리를 검토할 때 특정 자식 스레드(child thread)가 왜 존재했는지에 대한 질문입니다.

MultiAgentV2 암호화의 맥락과 역사

MultiAgentV2는 Codex CLI 하위 에이전트 시스템의 2세대 버전입니다. 첫 번째 버전은 에이전트 간의 메시지를 엔드 투 엔드(end-to-end) 평문(plain text)으로 조정했습니다. PR #26210에서 도입된 암호화는 에이전트 간 메시지 내용이 노출되어서는 안 되는 표면에 노출되지 않도록 하는 것을 목표로 합니다. 이는 Codex CLI가 공유 환경에서 실행되거나 페이로드(payload)가 제3자가 검사할 수 있는 채널을 통해 전송되는 경우라면 합리적인 조치입니다.

보고서 자체에서도 해당 암호화 전달 방식을 되돌려 달라고 요청하는 것은 아님을 명시하고 있습니다. 이의 제기는 더 구체적입니다. 모델로의 전달을 암호화하는 것이, 무엇이 위임되었는지 감사(audit)하기 위해 인간에게 필요한 읽기 가능한 복사본을 삭제하는 것을 의미해서는 안 된다는 것입니다. 이는 PR #26210이 단일 메커니즘으로 해결해 버린 두 가지 서로 다른 우려 사항입니다.

이 이슈를 동일한 변경 사항과 관련하여 이전에 오픈된 issue #26753과 구분할 필요가 있습니다. 해당 보고서는 모델이 암호화된 도구 (encrypted tools)를 수락하도록 설정되지 않았을 때 spawn_agent 스키마를 검증하는 과정에서 발생하는 400 에러를 설명합니다. 즉, 호출 자체가 수락되지 않는 결함입니다. 반면, #28058은 암호화된 메시지가 이미 성공적으로 수락 및 전달된 후에 발생합니다. 문제는 메시지가 수락된 후, 그 내용이 무엇이었는지 읽을 수 있는 흔적이 남지 않는다는 점입니다.
content 필드가 비어 있게 되며, 암호화된 페이로드 (payload)만 남게 됩니다.

MultiAgentV2의 기술적 세부 사항 및 암호화 성능

범위를 이해하기 위해 PR #26210 적용 전후의 메시지 차이를 살펴보는 것이 좋습니다. 이전에는 에이전트 간의 메시지가 단순화하면 다음과 같이 보였습니다:

{
  "author": "orchestrator",
  "recipient": "agent-refactor-1",
...

변경 후, MultiAgentV2가 암호화된 메시지를 전달하면 히스토리(history)에는 동일한 유형의 입력이 다음과 같이 남습니다:

{
  "author": "orchestrator",
  "recipient": "agent-refactor-1",
...

content 필드는 빈 문자열로 남고, 모든 유용한 텍스트는 수신자만이 복호화할 수 있는 블롭 (blob)인 encrypted_content 내에 존재하게 됩니다. 이슈에서 인용된 소스 코드에 나타난 실제 구조 정의는 다음과 같습니다:

pub struct InterAgentCommunication {
    pub id: Option,
    pub author: AgentPath,
...

다음 표는 두 가지 메시지 생성 경로 간의 동작 변화를 요약합니다:

⚠️ 주의: 이것은 암호화 취약점이 아닙니다. 문제는 메시지가 제대로 보호되지 않는 것이 아니라, 암호화된 이후 로컬에서 히스토리를 감사(audit)하는 사람을 위해 읽을 수 있는 복사본이 전혀 남지 않는다는 것입니다.

자신의 히스토리를 조사하는 방법

0.137.0 이후의 빌드에서 MultiAgentV2가 활성화된 Codex CLI를 사용하는 경우, 세션 히스토리가 저장되는 롤아웃 (rollout) 파일을 직접 확인하여 해당 동작을 확인할 수 있습니다.

# macOS / Linux
grep -o '"encrypted_content":"[^"]*"' ~/.codex/sessions/*/rollout.jsonl | head -5

...

만약 위의 명령어가 결과를 반환하면서 동시에 해당 엔트리들의 content 필드가 비어 있다면, 귀하의 설치 환경은 이슈(issue) #28058에 보고된 것과 동일한 동작을 보이고 있는 것입니다. MultiAgentV2가 활성화되지 않은 세션이나 2026년 6월 5일 이전의 세션과 비교하여 content가 읽기 가능한 상태인지 차이점을 확인할 수 있습니다.

해당 보고서 자체에는 암호화를 비활성화하고 읽기 가능한 필드를 복구하기 위한 설정 플래그 (flag)를 제공하지 않습니다. 현재로서는 텍스트를 볼 수 있는 유일한 방법은 롤아웃 (rollout)에 의존하지 않고, 암호화되기 전 오케스트레이터 (orchestrator) 측에서 작업을 캡처하는 것뿐이며, 이는 대부분의 워크플로우 (workflow)에서 기본적으로 수행하지 않는 작업입니다.
PR #26210은 2026년 6월 5일에 머지 (merge)되었습니다.

영향 및 분석

이 영향은 주로 두 그룹에 미칩니다: 프로덕션 (production) 환경에서 에이전트 (agent)가 무엇을 수행했는지 감사 (audit)하는 팀, 그리고 서브 에이전트 (subagent)가 왜 예상치 못한 작업을 실행했는지 디버깅 (debug)하는 개발자들입니다. 두 경우 모두 역사적으로 그 해답은 로컬 롤아웃 (rollout)에 존재해 왔으나, MultiAgentV2 암호화로 인해 페이로드 (payload)를 복호화하지 않는 한 그 해답은 사라지게 됩니다. 해당 이슈는 이를 사람이 자신의 히스토리를 검토하는 일반적인 흐름의 일부로 설명하고 있지 않습니다.

이 패턴은 Codex CLI에만 국한된 것이 아닙니다: 종단간 (end-to-end) 페이로드를 암호화하는 모든 시스템은 기밀성 (confidentiality)과 감사 가능성 (auditability) 사이에서 동일한 긴장에 직면합니다. 차이점은, 의사결정을 내리고 코드 변경을 실행하는 에이전트 파이프라인 (pipeline)에서 누가 누구에게 무엇을 요청했는지에 대한 추적 가능성 (traceability)은 선택적인 사치가 아니라는 점입니다. 이는 리포지토리 (repository)가 왜 특정 상태로 종료되었는지를 재구성할 수 있는 유일한 방법입니다.

다음 다이어그램은 spawn_agent 흐름 내에서 정보가 어디에서 손실되는지를 요약합니다:

sequenceDiagram
participant M as Agente padre
participant W as Codex CLI
...

해당 이슈(issue) 자체에서 제안하는 해결책은 구체적입니다. 모델에 전달하기 위해 message 필드는 암호화된 상태로 유지하되, 롤아웃 (rollout), 히스토리 (history), 트레이스 (trace)의 메타데이터에 영구 저장되는 암호화되지 않은 별도의 감사 (auditing) 필드를 추가하는 것입니다. 모델을 위한 채널과 감사하는 인간을 위한 채널을 분리하는 이러한 방식은, 비즈니스 페이로드 (payload)는 암호화하면서 감사 메타데이터는 평문으로 유지하는 로깅 시스템의 기본 원리와 본질적으로 동일합니다.

💭 핵심: 이 이슈는 암호화를 되돌려 달라는 것이 아닙니다. 모델에 전달되는 내용을 암호화하는 것이, 작업 이후에 아무도 감사할 수 없음을 자동으로 의미해서는 안 된다고 요구하는 것입니다.

다음 단계

이 노트를 작성하는 시점에, openai/codex 트래커의 이슈 #28058은 CLI, bug, subagent 태그가 붙은 상태로 여전히 열려 있으며, 아직 연결된 수정용 풀 리퀘스트 (pull request)는 없습니다. 보고서는 수정 사항이 가져야 할 형태를 명시하고 있습니다: 모델이 보는 message와는 독립적이며, 롤아웃, 히스토리, 트레이스 메타데이터에 저장되는 암호화되지 않은 감사 필드입니다.

감사가 중요한 워크플로우(컴플라이언스 검토, 인시던트 디버깅, 에이전트가 다른 에이전트에게 무엇을 위임하는지에 대한 제어)에서 이미 MultiAgentV2를 실행 중인 팀의 경우, 수정 사항이 나올 때까지의 실질적인 권장 사항은 암호화된 롤아웃을 유일한 신뢰할 수 있는 소스 (source of truth)로 의존하지 않는 것입니다. 즉, MultiAgentV2가 암호화하기 전에 오케스트레이터 (orchestrator) 측에서 작업을 기록하십시오.

📖 Telegram 요약: 요약 보기

직접 확인해 보세요: 자신의 MultiAgentV2 세션에 대해 grep -o "encrypted_content" ~/.codex/sessions/*/rollout.jsonl를 실행하여 로컬 히스토리에서 위임된 작업의 읽기 가능한 텍스트를 이미 상실했는지 확인하십시오.

자주 묻는 질문 (FAQ)

Codex CLI에서 MultiAgentV2란 무엇인가요?

Codex CLI에서 에이전트가 spawn_agent, send_message, followup_task 호출을 사용하여 여러 에이전트 간에 코드 작업을 분배하고 하위 에이전트(subagents)를 조정할 수 있도록 하는 시스템입니다.

PR #26210에서 정확히 무엇이 변경되었나요?

수신 모델이 보는 메시지 페이로드(payload)를 암호화했으며, 이로 인한 부작용으로 이전에 로컬 히스토리에 읽을 수 있는 텍스트를 저장하던 content 필드가 비어 있게 되었습니다.

제 설치 환경이 영향을 받았는지 어떻게 알 수 있나요?

MultiAgentV2가 활성화된 상태에서 0.137.0 이후의 빌드를 실행 중이라면, 롤아웃(rollout) 파일을 확인하십시오. 에이전트 간 메시지에서 encrypted_content는 채워져 있고 content는 비어 있다면, 이는 issue #28058의 동작을 보고 있는 것입니다.

암호화 자체에 보안 결함이 있나요?

해당 issue의 문서에 따르면 그렇지 않습니다. 문제는 암호화의 강도가 아니라, 로컬의 인간 감사(human audit)를 위한 읽을 수 있는 복사본이 손실되었다는 점입니다.

issue #26753과는 무엇이 다른가요?

#26753은 모델이 암호화된 도구 스키마를 수락하도록 설정되지 않았을 때, 스키마 검증 과정에서 발생하는 400 에러를 설명합니다. 즉, 호출이 완료되기 전에 실패합니다. 반면 #28058은 메시지가 성공적으로 전달된 이후에 발생하며, 메시지 내용에 대한 읽을 수 있는 기록이 남지 않는 문제입니다.

이미 수정 사항이 나와 있나요?

이 노트 작성 시점에는 없습니다. 해당 issue는 여전히 열려 있으며 연결된 수정용 풀 리퀘스트(pull request)도 없습니다. 다만, 보고서에서는 암호화된 페이로드와 분리된, 암호화되지 않은 감사용 필드를 만드는 구체적인 해결책을 제안하고 있습니다.

참조