Claude Code 세션 간 메시징: 동작 원리, 신뢰 모델, 다섯 가지 패턴

v2.1.224부터 Mac이나 Linux에서 실행되는 모든 대화형 Claude Code 세션은 시작하는 순간 Unix 소켓을 바인딩하고, 여러분이 실행 중인 다른 세션은 그 소켓에 텍스트 메시지를 넣을 수 있습니다. 제 경우 /tmp/cc-socks/38590.sock에 소유자 전용 권한으로 자리 잡고 있습니다.¹ 네이티브 Windows는 대신 명명된 파이프를 사용하며, 릴리스 노트 기준 v2.1.239부터 지원됩니다. 늦게 바인딩되는 예외 하나는 아래 함정 절에서 다룹니다. 이 기능을 움직이는 도구는 두 가지입니다. ListAgents는 여러분의 세션 중 어디에 닿을 수 있는지 찾아내고, SendMessage는 그중 하나에 이름을 지정해 메시지를 전달합니다.² 따로 켤 것도, 설정할 것도 없습니다. 두 세션이 같은 컴퓨터에서 v2.1.224 이상(Windows에서는 v2.1.239 이상)으로 돌아가고 있다면 이미 대화가 가능한 상태입니다.

Claude Code 세션은 로컬 Unix 소켓(v2.1.239부터 네이티브 Windows에서는 명명된 파이프)을 통해 서로 메시지를 주고받습니다. ListAgents가 닿을 수 있는 세션을 찾고, SendMessage가 그 세션에 이름을 지정해 평문을 전달합니다. 메시지는 입력일 뿐 결코 권한이 아닙니다. 메시지로는 승인 요청에 답할 수도, 설정을 바꿀 수도, 명령을 실행할 수도 없으며, 대화 기록이나 파일도 함께 넘어가지 않습니다.

핵심 요약

이제 Claude Code 세션끼리 메시지를 주고받을 수 있습니다. 같은 컴퓨터 안에서는 Anthropic 서버를 전혀 거치지 않는 로컬 소켓으로, 다른 컴퓨터와는 Remote Control을 통해 오갑니다(출시 시점에는 답장만 가능했고, v2.1.225에서 이름을 지정해 먼저 대화를 시작하는 기능이 추가됐습니다).¹⁵ 메시지는 순수한 텍스트뿐이며 대화 기록이나 파일, 권한은 절대 넘어가지 않고, 받는 세션은 이를 권한이 아닌 입력으로 취급합니다. 즉 메시지로는 승인 요청에 답할 수도, 설정을 바꿀 수도, 명령을 실행할 수도 없습니다.¹ 이 기능은 제각각 돌아가던 터미널 무리를 팀에 가까운 무언가로 바꿔놓으며, 가장 잘 맞는 쓰임새는 그동안 손으로 날라야 했던 조율용 알림입니다. “마이그레이션 끝났습니다”, “그 컬럼 이름 바꿨습니다”, “이제 main에 rebase해도 안전합니다” 같은 것들이죠. 가장 날카로운 함정은 아무 소리 없이 사라지는 경우입니다. 서로 관련 없어 보이는 네 개의 프라이버시 환경 변수가 값에 따라 각각 이 기능을 조용히 꺼버릴 수 있습니다.³ 출시 이후 v2.1.239에서 Windows가 네이티브로 합류했고, v2.1.236에는 notify_when_idle이 추가되어 같은 컴퓨터의 상대 세션에 다음번 유휴 상태에 들어가거나 종료될 때 알림 한 번을 보내 달라고 요청할 수 있게 됐습니다.⁹¹⁰

무엇이 출시됐나

v2.1.224 릴리스는 macOS와 Linux에서 세션 간 SendMessage와 ListAgents 탐색 기능을 추가했습니다. 이어진 v2.1.225는 여기서 한 걸음 더 나아가, 다른 컴퓨터의 Remote Control 세션에 대해 먼저 대화를 걸 수 있게 했습니다. 그전까지는 답장만 가능했습니다.⁴⁵

내부 동작을 직접 들여다볼 수 있는 창구는 세 곳입니다.

• /list-agents(별칭 /peers)는 첫 줄에 세션 자신의 이름(다른 세션이 이 세션에 닿을 때 쓰는 이름으로, v2.1.239부터 표시)을 출력한 뒤, Claude가 닿을 수 있는 모든 세션을 보여줍니다. 현재 세션 안의 서브에이전트, 세션의 활성 에이전트 팀 팀원(v2.1.239부터 표시되며, 그전에는 닿을 수 있는 팀원이 없는 것처럼 보였습니다), 백그라운드를 포함한 여러분의 다른 로컬 세션, 그리고 Remote Control이 연결된 동안에는 다른 컴퓨터의 세션과 웹의 Claude Code 세션까지 나옵니다.¹⁹
• /status에는 Peer address 행이 있어 세션 자신의 수신함 소켓을 uds: 접두사와 함께 보여줍니다.¹
• CLAUDE_CODE_MESSAGING_SOCKET은 수신함이 바인딩된 뒤(함정 절의 늦은 바인딩 설명 참고) Claude Code가 훅과 Bash 명령에 내보내는 환경 변수로, 세션 자신의 소켓 경로를 담고 있습니다.¹⁶ 이게 왜 중요한지는 아래에서 더 다룹니다.

2026년 8월 25일 제 컴퓨터에서 Claude Code 2.1.246으로 직접 확인해 봤습니다. 에이전트 목록은 “This session is blakecrosley-com-76 [04e18a] — the name other sessions use to message it (it is not listed below; a message to it would be a message to yourself).”(이 세션의 이름은 blakecrosley-com-76이며 다른 세션이 이 세션에 메시지를 보낼 때 쓰는 이름이라는 안내)라는 줄로 시작했고, 이어서 “resumegeni-25 [10d770] · interactive · idle · started 21h ago” 같은 행으로 11개의 상대 세션이 나왔습니다. 이름은 디렉터리 이름에 두 글자 접미사가 붙은 형태이고 그 뒤에 대괄호 안의 짧은 식별자가 따라오며, 상태는 idle, busy, shell 중 하나이고, 행마다 시작 후 경과 시간이 표시되며, 세션 자신의 자식 세션은 별도의 Subagents 블록에 묶여 있었습니다. /tmp/cc-socks/ 아래 소켓 파일에는 srw------- 권한이, 디렉터리 자체에는 drwx------ 권한이 붙어 있습니다. 제 계정만 읽고 쓸 수 있다는 뜻이고, 공용 컴퓨터에서는 바로 이 권한이 경계선 역할을 합니다.¹

세션은 이름으로 서로를 부릅니다. /rename이나 --name 플래그로 직접 지정할 수 있고, 그러지 않으면 Claude Code가 작업 디렉터리에서 my-app-3f 같은 이름을 만들어 냅니다.¹¹¹ v2.1.232부터는 대화형 세션을 시작하거나 재개하거나 이름을 바꿀 때 같은 컴퓨터의 다른 활성 세션이 이미 쓰는 이름과 겹치면, Claude Code는 그 이름을 원래 세션에 남겨두고 여러분의 세션에는 name-word-word 형태의 변형 이름(예를 들어 auth-refactor-graceful-unicorn 같은 것)을 붙인 뒤 그 사실을 알려줍니다.¹¹⁰ 다만 한쪽 세션이 구버전으로 돌아가거나, 겹친 이름이 Claude Code가 자동 생성한 이름이거나, 백그라운드 세션이나 -p 세션을 Claude Code가 시작 시점에 검사하지 않는 --name으로 띄운 경우에는 충돌이 그대로 남습니다.¹¹ 목록에는 항상 각 로컬 세션의 작업 디렉터리가 표시되므로, 같은 이름의 세션이 서로 다른 디렉터리에서 돌아갈 때는 그것으로 구분할 수 있습니다. 이름이 겹치면 Claude는 각 행에 짧은 식별자를 덧붙이고 주소 지정에도 그 식별자를 사용합니다. 클라우드나 Remote Control 세션 목록이 Claude Code가 읽는 제한된 페이지 수를 넘어선 계정처럼, 세션이 실행되는 모든 곳을 Claude Code가 확인하지 못한 경우에도 Claude는 같은 짧은 식별자 방식의 주소 지정으로 대체합니다.¹

출시 이후 무엇이 바뀌었나(2026년 8월)

출시 후 2주 동안 나온 다섯 번의 릴리스가 이 글이 지적했던 Windows 공백을 메우고, 이름 지정과 주소 지정을 다듬었으며, 이 글이 미처 지적하지 못한 네 가지 조용한 실패 모드를 닫았습니다.⁹¹⁰

실질적인 효과는 이렇습니다. 아래의 “보고하는 장기 실행 세션” 패턴에는 더 이상 확인용 프롬프트가 필요 없습니다. 지켜보는 세션이 notify_when_idle로 장기 실행 세션에 유휴 알림 한 번을 요청해 두면, 그 세션이 다음번 유휴 상태에 들어가거나 종료될 때 소식을 듣게 됩니다. 네 가지 실패 모드 가운데 둘(너무 큰 메시지, 수신함이 감당하지 못할 만큼 빠른 연속 전송)은 이제 보내는 쪽에서 미리 실패하고, 나머지 둘(거부되거나 버려진 메시지)은 같은 컴퓨터의 대화형 발신자에게 명시적인 보고로 되돌아옵니다.

진짜 재미있는 부분은 신뢰 모델

Anthropic의 설계는 대부분의 멀티 에이전트 시스템이 얼버무리는 질문에 답을 내놓습니다. 다른 에이전트가 보낸 메시지는 과연 어느 정도의 무게를 갖는가? 여기서의 답은 명확합니다. 메시지는 정보일 뿐, 결코 권한이 아닙니다.¹

세션 A가 세션 B에 메시지를 보낼 때, 도착한 내용은 네 가지 규칙에 묶입니다.¹

1. 무엇도 승인할 수 없습니다. B에 떠 있는 권한 요청은 A가 무슨 말을 하든 무시합니다. 요청에 답하는 것은 오직 사람입니다.
2. 설정을 바꿀 수 없습니다. 받는 쪽 Claude는 다른 세션이 요청했다는 이유로 권한 설정이나 CLAUDE.md, 그 밖의 어떤 설정도 건드리지 말라는 지시를 받습니다.
3. 명령은 텍스트로 도착합니다. 메시지 본문에 적힌 /compact는 실행되는 명령이 아니라 그냥 여덟 글자짜리 문장일 뿐입니다.
4. 권한 요청은 여전히 뜹니다. 메시지 내용대로 움직이려는데 B에게 없는 권한이 필요하다면, 다른 작업과 똑같이 요청 창이 나타납니다.

수신 쪽에도 별도의 관문이 있습니다. 도착하는 메시지는 전달, 사용자 승인 대기, 거부 중 하나의 결과로 처리되며, 이는 crossSessionInbound 설정(accept, hold, refuse)으로 제어합니다.¹ 아무것도 지정하지 않으면 Claude Code가 두 세션의 권한 모드를 보고 메시지마다 판단하는데, 그 기본 논리가 꽤 우아합니다. 권한 요청을 건너뛰는 세션이 한 부류, 나머지가 다른 한 부류가 됩니다(우회가 가능한 세션의 plan 모드는 건너뛰는 쪽으로, auto와 acceptEdits, dontAsk는 요청을 띄우는 쪽으로 칩니다). 요청을 띄우는 세션은 메시지를 자유롭게 받되 건너뛰는 세션에서 온 것은 보류하고, 건너뛰는 세션은 같은 부류에서 온 메시지를 빼면 전부 보류합니다.¹ 이 비대칭은 의도된 설계입니다. 메시지가 관대한 세션의 권한에 편승해서는 안 된다는 원칙이고, v2.1.222가 auto 모드의 발신 쪽에 적용한 것(권한 분류기가 전송 전에 모든 발신을 검토합니다)을 v2.1.224가 수신 쪽에도 적용한 셈입니다.⁷

보류된 메시지는 발신자와 미리보기를 보여주는 승인 창을 띄웁니다. 답하지 않은 창은 5분 뒤 만료되고(dialogExpiry로 조정 가능) 메시지는 버려집니다.¹ 터미널이 붙어 있지 않은 백그라운드 세션은 그 기한이 지나도 창을 계속 열어두며, 여러분이 터미널을 붙인 뒤에도 창이 기한 한 번 분량만큼 더 답 없이 남아 있을 때만 메시지가 버려집니다.¹ 동시에 보류할 수 있는 메시지는 최대 100건입니다.¹ 범위를 더 좁히는 장치도 두 가지 있습니다. isolatePeerMachines: true는 bypassPermissions 모드에서조차 메시지가 컴퓨터 밖으로 나가기 전에 명시적 승인을 요구하며, 어느 설정 범위에서든 true 하나면 그 값이 이깁니다. 그래서 저장소에 커밋된 프로젝트 설정 파일은 이 조임쇠를 더 죌 수는 있어도 풀 수는 없습니다.¹ 조직 차원에서는 SendMessage와 ListAgents에 거부 규칙을 걸고 관리 설정에 crossSessionInbound: "refuse"를 넣어 기능을 통째로 차단할 수 있습니다.¹

메시지가 오가는 경로

상대 세션이 어디에서 돌아가느냐에 따라 전송 경로와 보낼 수 있는 내용이 함께 달라집니다.¹

이 글이 처음 나갔을 때 Anthropic 문서 페이지는 컴퓨터를 넘나드는 메시지를 여전히 모두 답장만 가능하다고 설명했던 반면, v2.1.225 릴리스 노트는 SendMessage가 “can now start a conversation with your Remote Control sessions on other machines by name.”(이제 다른 컴퓨터의 Remote Control 세션에 이름을 지정해 대화를 시작할 수 있다)이라고 밝혔습니다. 그 뒤 문서가 릴리스를 따라잡았습니다. 이제 문서 페이지는 여러분의 다른 컴퓨터에 있는 세션과 대화를 시작하려면 v2.1.225 이상과 목록에 나타나는 대상이 필요하다고 명시합니다.¹⁵

같은 컴퓨터인지 아닌지를 가르는 기준은 파일 시스템의 가시성입니다. 세션은 디스크의 파일에 자신을 등록하므로, 두 세션은 같은 파일을 볼 수 있을 때만 서로에게 닿습니다. 컨테이너 안의 세션과 호스트의 세션은 대화할 수 없지만, 같은 컨테이너 안의 두 세션은 가능합니다.¹

전달은 받는 세션의 호흡을 존중합니다. 받는 쪽 Claude는 작업이 진행 중일 때 도구 호출 사이에 메시지를 읽고, 실행 중인 도구를 중간에 끊는 일은 없으며, 세션이 놀고 있을 때는 Claude Code가 그 메시지로 새 차례를 시작합니다.¹ 전달된 메시지는 여러분이 직접 입력한 프롬프트와 마찬가지로 사용량에 잡힙니다.¹

만들어 볼 만한 다섯 가지 패턴

1. 워크트리 조율. 가장 뻔하면서도, 공식 문서가 예시 메시지로 직접 보여주는 사례이기도 합니다. 같은 저장소를 각자의 워크트리에서 다루는 세션들이 무엇이 반영됐는지 서로 알려주는 것입니다.¹ “Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.”(스키마 마이그레이션 완료: 새 컬럼은 tenant_id이고, 이제 main에 rebase해도 안전합니다) 같은 소식은 원래라면 여러분이 직접 눈치채고, 터미널을 옮기고, 다시 타이핑해야 전달됩니다. 워크트리 대신 여러 세션이 하나의 체크아웃을 공유한다면 조율 메시지의 가치는 한층 더 커집니다. “지금 content/guides/를 커밋할 참이니 스테이징하지 마세요” 한 줄이, 한 세션이 다른 세션의 미완성 작업을 커밋해 버리는 고전적인 공유 트리 충돌을 막아줍니다.

2. 감시자와 작업자. 배포나 테스트 스위트, 로그를 지켜보는 감시 세션을 하나 띄워두고, 무언가 깨지는 즉시 수정을 맡은 세션에 알리게 하는 방식입니다. 받는 세션은 그 발견을 명령이 아니라 맥락으로 받아들이며, 무엇을 할지는 여전히 자기 권한 안에서 스스로 판단합니다. 여기에 백그라운드 세션과 알림 훅을 엮으면, 정말 필요할 때만 사람에게 도달하는 단계적 에스컬레이션 사슬이 만들어집니다.

3. 보고하는 장기 실행 세션. 한 세션에서 마이그레이션이나 긴 테스트를 돌려놓고, 여러분이 실제로 보고 있는 세션에 결과를 보고하게 하는 방식입니다.¹ 상태 정보가 잊힌 터미널 안에서만 머무르는 일이 사라집니다. 반대 방향도 됩니다. 지켜보는 쪽에서 물으면 되니까요. “다른 터미널에서 돌아가는 세션에 마이그레이션이 끝났는지 물어봐 줘”라고 한 줄 던지면 Claude가 상대를 찾고, 주소를 지정하고, 문장을 다듬는 일까지 알아서 처리합니다.¹ v2.1.236부터는 묻는 과정마저 생략할 수 있습니다. 지켜보는 세션이 장기 실행 세션에 notify_when_idle을 걸어두면, 그 세션이 다음번 유휴 상태에 들어가거나 종료될 때 한 번 보고해 오며, 어느 쪽도 폴링하지 않습니다.¹¹⁰ 두 세션 모두 v2.1.236 이상이어야 하고, 제한은 수신 제어 설정을 따릅니다. 모든 구독에는 12시간 상한이 있어서, 그때까지 알림이 오지 않으면 Claude Code가 구독을 버리고 Claude에게 더 기다리지 말라고 알립니다. 지켜보는 대상 쪽이 refuse이면 그 세션은 요청을 기록하지도 답하지도 않고 버리므로 구독은 상한까지 답 없이 만료되고, 요청하는 쪽이 refuse이면 Claude Code는 아예 구독하지 않습니다. 어느 쪽이든 hold이면 알림이 불완전하게 도착합니다. 지켜보는 대상 세션은 한 줄짜리 상태를 빼고 보내고, 요청한 세션은 알림을 Claude에게 전달하지 않은 채 여러분의 대화 기록에만 표시합니다.¹

4. 무인 작업자 집단. 헤드리스 claude -p 세션도 수신함 소켓을 바인딩하므로, 오래 도는 -p 작업자가 메시지를 받을 수 있고 목록에도 나타납니다.⁸ 다만 걸리는 지점이 있습니다. -p 세션은 승인 창을 띄울 수 없어서, 기본 보류된 메시지는 dialogExpiry 기한(기본 5분이며, dialogExpiry에는 60s, 5m, 10m, never를 쓸 수 있습니다)을 채운 뒤 버려지고, 닿을 수 있는 발신자에게 만료됐다고 보고합니다. 그 시간 안에 모드나 설정이 바뀌어야만 전달됩니다.¹ 메시지가 보류된 채 세션이 종료되면, Claude Code는 닿을 수 있는 각 발신자에게 그 메시지들이 만료됐다고 보고합니다.¹ v2.1.225 이전에는 기한 자체가 없었습니다. 보류된 메시지는 아무 안내도 만료도 없이 방치됐고, 보류 메시지를 안은 채 종료된 작업자는 발신자에게 아무것도 알리지 않았습니다.¹ 메시지를 받는 무인 작업자를 띄우려면 그 세션의 --settings 값에 crossSessionInbound: "accept"를 넣어 시작하세요. 사용자 설정에 accept를 넣어 실행하는 모든 세션에 적용해 버리는 대신, 작업자별로 권한을 주는 방식입니다.⁸ bare 모드 세션은 소켓 자체를 건너뛰므로 아예 닿을 수 없습니다.⁸

5. 스크립트가 넣는 수신함. 조용한 실세는 이쪽입니다. Claude Code가 CLAUDE_CODE_MESSAGING_SOCKET을 훅과 Bash 명령에 내보내기 때문에, 스크립트가 세션 자신의 수신함에 직접 글을 넣을 수 있습니다.⁶ Claude Code는 자기 자식 프로세스가 보낸 메시지를 검증합니다. 훅이나 명령이 자기 세션으로 되돌려 보내는 메시지는 명시적인 crossSessionInbound 설정이 없다면 별다른 절차 없이 전달됩니다.¹ 세션 자신의 커밋이 발동시킨 git 훅, 세션이 띄운 테스트 래퍼, 세션이 실행한 배포 스크립트까지, 세션 스스로 시작한 훅이나 Bash 명령이라면 무엇이든 그 세션에 맥락 한 줄을 되돌려 넣을 수 있습니다. 다만 Claude Code가 그 발신자를 자기 자식으로 검증할 수 있어야 합니다. 프로세스 증거로도 토큰으로도 검증할 수 없으면 아무 권한 부류도 주장하지 않는 메시지로 취급하므로, 권한을 건너뛰는 세션은 그 메시지를 전달하는 대신 여러분의 승인을 기다리며 보류합니다.¹ 네이티브 Windows에서는 연결의 첫 줄이 CLAUDE_CODE_MESSAGING_TOKEN을 담은 인증 줄이어야 하며, 그렇지 않으면 Claude Code는 읽지 않고 연결을 닫습니다. Windows에서 자기 자식의 메시지를 검증하는 유일한 방법도 그 토큰입니다.¹ Linux에서는 글을 넣은 프로세스가 종료된 뒤에도 프로세스 증거 검사가 동작하지만, macOS에서는 그 프로세스가 살아 있는 동안에만 가능합니다. macOS에서 프로세스가 종료된 뒤, 그리고 Claude Code가 PID 1인 컨테이너에서는, 세션이 내보낸 CLAUDE_CODE_MESSAGING_TOKEN을 인증 줄에 담아 보낸 자식을 대신 검증합니다.¹ 샌드박스에서 실행되는 명령은 소켓을 허용해 줘야 합니다. macOS에서는 sandbox.network.allowUnixSockets에 소켓 경로를 나열하고, seccomp 필터가 경로를 검사할 수 없는 Linux와 WSL 2에서는 sandbox.network.allowAllUnixSockets: true만이 길을 열어줍니다. 그 선택적 필터가 설치되어 있지 않다면 샌드박스는 애초에 소켓을 막지 않습니다.¹¹²

이 기능이 되기를 거부하는 것들

여기서의 한계는 모두 설계상의 결정이며, 그것을 존중하면 엉뚱한 것을 만드는 일을 피할 수 있습니다.

승인 통로가 아닙니다. 신뢰 모델의 모든 요소는 한 세션이 다른 세션의 행동을 허가하는 것을 막기 위해 존재합니다. “세션 A가 승인하면 세션 B가 실행한다” 형태의 흐름은 명시적으로 배제된 설계입니다. 권한은 언제나 사람을 거쳐야 합니다.¹

맥락 이전이 아닙니다. 메시지는 한 Claude가 다른 Claude에게 쓰는 텍스트일 뿐, 대화 기록이나 파일이 아닙니다. Anthropic 문서는 이를 분명히 말합니다. 대화를 옮기고 싶다면 그 세션을 이어서 실행하라는 것입니다.¹ 요약해서 전하세요. 통째로 쏟아붓지 마세요.

에이전트 팀이 아닙니다. 독립된 세션들이 서로 메시지를 주고받는 것은 대등한 관계의 사례입니다. Claude가 직접 만들고 감독하는 조직된 팀, 즉 정해진 형식의 프로토콜 메시지와 명단, 공유된 작업 상태를 갖춘 구조는 에이전트 팀 기능의 몫이고, 형식을 갖춘 팀 메시지는 의도적으로 팀 내부에만 머무릅니다.¹ 세션 간 텍스트 위에 나름의 메시지 프로토콜을 설계하고 있다면, 여러분에게 필요한 것은 에이전트 팀입니다.

채팅 루프가 아닙니다. Claude Code는 발신자별로 반복 메시지에 속도 제한을 걸고, 짧은 시간 안에 도착한 똑같은 메시지는 버리며, 읽지 않은 수신 메시지를 세션당 50건으로 제한합니다. 그래서 두 세션 사이의 메시지 루프는 설계상 저절로 굶어 죽습니다.¹ v2.1.236은 여기에 더해, 짧은 시간에 몰아친 메시지가 받는 쪽 수신함의 수용량을 넘어설 경우 받는 쪽에서 버려지는데도 보냈다고 보고하는 대신 추가 메시지를 보내기 전에 거부합니다.¹⁰ 대화가 아니라 요청과 응답의 교환을 만드세요.

함정들

프라이버시 환경 변수가 조용히 기능을 꺼버립니다. 세션 간 메시징은 기능 플래그 평가에 의존하는데, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK 중 어느 하나라도 그 평가를 끌 수 있고, 그러면 메시징도 아무 말 없이 함께 내려갑니다.³ 진단은 /list-agents로 합니다. 명령 자체가 인식되지 않으면 그 세션에는 기능이 아예 없는 것이고, 명령은 동작하는데 보낸 메시지가 도착하지 않는다면 더 좁은 원인입니다. 거부 규칙이거나, 받는 쪽의 수신 제어 설정이거나, 목록에 없는 대상(Remote Control이 연결되지 않았거나, 세션이 Claude Code가 읽는 제한된 페이지 수 밖으로 밀려난 경우)이거나, v2.1.225 이전 버전의 발신자가 다른 컴퓨터와 대화를 시작하려 한 경우입니다.¹ 수신함을 바인딩한 적 없는 대상은 조용한 경우가 아닙니다. 프라이버시 변수 뒤에 있거나, bare 모드이거나, 컨테이너 경계 너머에 있는 세션은 /list-agents에 아예 나타나지 않으므로, 그 세션에 보내면 Claude Code가 찾을 수 없는 이름이라며 요란하게 실패합니다. 그리고 v2.1.234부터 SendMessage는 보이지 않는 세션을 없는 것으로 취급하는 대신, 세션 목록을 완전히 확인하지 못했을 때 그 사실도 말해줍니다.¹³¹⁰ 업그레이드 후 첫 세션은 없는 것이 아니라 늦게 바인딩되는 것입니다. Claude Code는 기능 플래그 가져오기가 끝나는 즉시 수신함을 바인딩하고 소켓 변수를 내보내며, v2.1.228은 그 첫 세션이 때때로 수신함 없이 시작되던 문제를 고쳤습니다.¹¹⁰ 진짜 조용한 경우는 보내는 쪽에 있습니다. 문서가 보류 알림과 그 후속 알림, 도착 시점의 거부 알림, 폐기 알림을 약속하는 대상은 같은 컴퓨터의 대화형 발신자뿐이므로, 다른 컴퓨터의 발신자나 -p 작업자에게는 그런 경우에 약속된 알림이 없습니다. 두 가지 보고는 “each sender it can reach”(닿을 수 있는 각 발신자)에게 전달됩니다. 기본 보류된 메시지의 만료, 그리고 설정 변경으로 보류 메시지가 버려질 때의 거부입니다. 명시적인 hold 설정으로 보류된 메시지는 절대 만료되지 않으므로, 그에 대한 만료 보고는 결코 돌아오지 않습니다.¹

플랫폼과 제공자의 공백. 네이티브 Windows 지원은 v2.1.239에 들어왔고, 그전에는 WSL 2 안의 Linux만 동작했습니다.¹⁹ Anthropic 문서 페이지는 Windows 최소 버전을 v2.1.234로 적고 있지만, 릴리스 노트는 v2.1.239에서 처음 발표합니다. 안전한 최소 버전은 v2.1.239로 보세요.¹⁹ 같은 컴퓨터의 WSL 2 안 세션과 네이티브 Windows 세션도 서로 닿지 못합니다. 서로 다른 홈 디렉터리에 등록되고, 서로 다른 종류의 소켓을 듣기 때문입니다.¹ Amazon Bedrock, AWS의 Claude Platform, Google Cloud의 Agent Platform, Microsoft Foundry에서는 사용할 수 없습니다.¹

한쪽으로만 열린 답장. 답장을 보내는 세션이 Remote Control에 연결되어 있지 않은 상태에서 다른 컴퓨터의 세션에 답장을 보내면, 메시지는 도착하지만 회신 주소가 없어 받는 쪽에서는 답할 수 없습니다. Claude Code는 보내는 시점에 Claude에게 그 사실을 알려주며, v2.1.225는 주소 지정을 더 엄격하게 다듬었습니다. Claude Code가 자기 세션 목록을 확인하지 못했을 때, 확인된 다른 컴퓨터의 수신자를 같은 이름의 로컬 세션으로 바꿔치기하는 일은 결코 없습니다.⁵

헤드리스 보류. 영문 모르게 메시지를 무시하는 -p 작업자는 십중팔구 보류 메시지 문제입니다. 창이 없으니 전달도 없는 것이죠. 메시지를 받아야 하는 작업자에는 crossSessionInbound: "accept"를 설정하세요.⁸

핵심 정리

Claude Code를 매일 쓰는 사용자라면: - /list-agents를 한 번 실행해 지금 여러분의 세션들이 어디까지 닿을 수 있는지 확인하세요. 중요한 세션은 /rename으로 이름을 붙여두면 메시지 주소 지정이 깔끔해집니다. 이 기능이 기대는 세션 명령과 설정은 Claude Code 가이드에서 다룹니다. - 메시지는 평범한 말로 시키면 됩니다(“결제 작업 중인 세션에 우리가 뭘 바꿨는지 알려줘”). 문장을 쓰는 일은 Claude가 알아서 합니다.¹

자동화를 만드는 사람이라면: - CLAUDE_CODE_MESSAGING_SOCKET을 통해 훅과 스크립트에서 세션으로 메시지를 넣으세요. 자기 자식 프로세스가 보낸 메시지는 Linux에서 승인 절차 없이 전달됩니다.¹⁶ - 무인 -p 작업자에게는 전역 설정이 아니라 각자의 --settings에 crossSessionInbound: "accept"를 주세요.⁸

팀과 보안 검토자라면: - 이 기능은 올바른 기본값을 갖고 출시됐습니다. 메시지에는 아무 권한도 실리지 않고, 권한 요청을 건너뛰는 세션은 기본적으로 격리되며, isolatePeerMachines와 관리 설정의 거부 규칙이 컴퓨터 단위와 조직 전체의 차단 스위치를 제공합니다.¹ - 메시지 기능이 고장 났다고 결론 내리기 전에 네 개의 프라이버시 환경 변수부터 점검하세요. 메시지를 거부하는 세션은 목록에서도 자기 /status에서도 똑같이 보이므로, 상태가 아니라 그 세션에 적용되는 설정 파일을 확인하세요. v2.1.238부터는 같은 컴퓨터의 세션에서 보낸 경우 거부 사실도 되돌아옵니다.¹¹⁰

자주 묻는 질문

Claude Code의 세션 간 메시징은 Windows에서 동작합니까?

그렇습니다. 릴리스 노트 기준으로 v2.1.239부터 네이티브로 동작하며, 동일한 SendMessage와 ListAgents 도구를 쓰고 Unix 소켓 자리에는 명명된 파이프가 들어갑니다. 그 이전에는 WSL 2 안의 Linux만 동작했습니다. Anthropic의 문서 페이지는 Windows 하한을 v2.1.234로 적어 두었지만, 안전한 하한은 v2.1.239로 잡는 것이 좋습니다. 같은 컴퓨터에 있는 WSL 2 세션과 네이티브 Windows 세션은 여전히 서로에게 닿지 못합니다.¹⁹

한 Claude Code 세션이 다른 세션의 권한 요청을 승인할 수 있습니까?

없습니다. 메시지는 정보일 뿐 결코 권한이 아닙니다. 대기 중인 권한 요청은 보내는 세션이 무슨 말을 하든 무시합니다. 그 요청에 답하는 사람은 오직 여러분뿐이기 때문입니다. Claude Code는 받는 쪽 Claude에게 다른 세션이 요청했다는 이유로 권한 설정이나 CLAUDE.md, 그 밖의 어떤 설정도 바꾸지 말라고 지시하며, 메시지 본문에 적힌 /compact는 실행된 명령이 아니라 여덟 글자짜리 문장에 지나지 않습니다.¹

다른 세션이 /list-agents에 나타나지 않는 이유는 무엇입니까?

프라이버시 관련 환경 변수부터 점검해야 합니다. 메시징은 기능 플래그 평가에 의존하는데, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK 가운데 어느 하나라도 그 평가를 꺼 버릴 수 있고, 그러면 메시징도 함께 조용히 내려갑니다. bare 모드인 세션이나 컨테이너 경계 너머에 있는 세션도 결코 나타나지 않습니다. 두 세션은 디스크에서 같은 파일을 볼 때에만 서로에게 닿기 때문입니다.¹³

무인 claude -p 작업자가 메시지를 받게 하려면 어떻게 합니까?

그 세션의 --settings 값에 crossSessionInbound: "accept"를 넣어 시작합니다. 사용자 설정에 accept를 넣어 실행하는 모든 세션에 적용해 버리는 대신, 작업자별로 권한을 주는 방식입니다. -p 세션은 수신함 소켓을 바인딩하고 목록에도 나타나지만 승인 창을 띄울 수 없으므로, 기본값대로 보류된 메시지는 dialogExpiry 기한을 다 채운 뒤 버려집니다.⁸

대화 기록이나 파일을 다른 세션에 보낼 수 있습니까?

없습니다. 메시지는 한 Claude가 다른 Claude에게 쓰는 평문일 뿐, 대화 기록도 파일도 권한도 아닙니다. Anthropic의 문서는 이를 분명히 밝힙니다. 대화를 옮기려면 그 대신 세션을 재개하라는 것입니다. 쏟아붓지 말고 요약하십시오. 그리고 세션 간 텍스트 위에 메시지 프로토콜을 설계하고 있다면, 여러분에게 실제로 필요한 것은 에이전트 팀입니다.¹

참고 자료