Claude Code 세션 간 메시지 교환 및 통신 방법

Claude Code 세션 간 메시지 교환의 의미

두 개의 Claude Code 세션은 동일한 머신에서 동일한 운영체제 사용자로 실행될 때 서로 메시지를 주고받을 수 있습니다. 메시지는 한 Claude가 다른 Claude를 위해 작성하는 단순 텍스트 조각입니다. 여기에는 대화 기록이나 파일이 포함되지 않습니다. Claude는 ListAgents 도구로 다른 세션을 찾고 SendMessage을 사용하여 텍스트를 전달하므로, 사용자가 직접 도구를 호출할 필요는 없습니다. 다른 세션이 알아야 할 내용을 말하면 Claude가 직접 메시지를 작성합니다.

이 기능을 세션 간 메시징(cross-session messaging)이라고 합니다. 2026년 10월 기준으로 macOS 및 Linux(WSL 2 내의 Linux 포함)에서는 Claude Code v2.1.224 이상이 필요하며, 네이티브 Windows에서는 v2.1.234 이상이 필요합니다. 동일 머신 내 세션 간 메시징은 Amazon Bedrock, AWS의 Claude Platform, Google Cloud의 Agent Platform, Microsoft Foundry를 포함한 모든 제공업체에서 작동합니다(단, 해당 제공업체 사용 시 v2.1.248 이상 필요). 다른 머신이나 클라우드에 있는 세션에 접근하는 범위는 더 제한적입니다. 이는 claude.ai 로그인이 필요한 Remote Control을 통해 이루어지므로, API 키를 사용하거나 앞서 언급한 4개의 제공업체 환경에서는 작동하지 않습니다. 세션이 이러한 요구 사항을 충족하면 메시징 기능은 이미 켜져 있으며 별도로 활성화할 설정은 없습니다. 아래에 설명된 동작은 세션 간 메시징에 대한 Anthropic 문서를 기반으로 합니다.

VPS는 세션이 오랫동안 유지되어 통신할 가치가 있기 때문에 이 기능이 중요합니다. 노트북은 덮개를 닫으면 세션이 종료되지만, tmux 환경의 서버에서는 월요일에 시작한 세션이 목요일까지 실행되며 하나의 저장소 컨텍스트를 유지합니다. 이러한 세션이 두 개 이상 존재하게 되면 세션 간 통신은 이론적인 영역을 넘어섭니다. 아직 환경을 구성하지 않았다면 이 가이드에서 전제로 하는 세션 구성을 다루는 tmux 환경에서 Claude Code 실행하기부터 시작하십시오.

토큰 비용을 고려해 두 번째 세션을 사용할 가치가 있는 경우

먼저 비용을 고려해야 한다. 각 세션은 자체 컨텍스트 창을 사용하는 별도의 Claude 인스턴스이므로, 같은 기간에 세션 2개를 사용하면 세션 1개를 사용할 때보다 비용이 대략 2배 든다. 전달된 메시지도 직접 입력한 프롬프트와 동일하게 사용량에 포함된다. 조정 작업에는 비용이 들며, 실제로 하나의 단계 흐름인 작업을 여러 세션으로 나누면 더 느리고 비싸진다.

두 번째 세션을 사용해 비용을 상쇄할 수 있는 경우에는 다음과 같은 공통점이 있다. 서로 기다리지 않고 두 작업을 동시에 실행하며, 그중 한 작업이 진행 중에 다른 작업에 필요한 정보를 얻는다.

• 한 세션이 호환성을 깨뜨리는 변경 사항을 발견하는 동안 다른 세션이 해당 변경으로 영향을 받은 코드를 기반으로 작업한다. Claude는 변경 사항을 요약해 다른 터미널에 다시 입력하지 않고 전달한다.
• 두 세션이 별도의 git worktree에서 같은 저장소를 작업하고, 한 세션이 다른 세션에서 반영된 내용을 알아야 한다.
• 오래 걸리는 마이그레이션 또는 테스트 실행이 결과를 보고, 사용자가 확인 중인 세션이 그 결과를 받는다.
• 빌더 세션과 리뷰어 세션을 함께 사용한다. 리뷰어 세션은 빌더 세션이 생성한 결과를 읽고 발견한 내용을 돌려보낸다.

작업이 순차적으로 진행되거나 두 세션이 같은 파일을 편집해야 한다면 세션 1개를 사용한다. 하나의 작업 안에서 Claude가 생성하고 감독하는 협업 그룹이 필요하다면 이는 agent teams이며, 별도의 아직 실험적인 기능이다. 다른 터미널에서 같은 대화를 이어가려는 것뿐이라면 세션을 resume한다. 세션 간 메시지 전달은 사용자가 직접 시작하고 제어하는 독립 세션에 사용한다.

기능을 활용하기 전에 해당 기능이 존재하는지 확인하십시오

먼저 버전을 확인합니다:

claude --version

해당 숫자를 2.1.224와 비교하십시오. 그런 다음 세션 내에서 /list-agents를 입력하십시오. 이 명령은 /peers으로도 실행할 수 있습니다. 이 명령은 현재 세션에서 접근 가능한 모든 에이전트와 각 에이전트가 응답하는 이름을 출력합니다. 명령 자체가 인식되지 않는다면 해당 세션은 세션 간 메시징 기능을 지원하지 않는 것이며, 어떤 crossSessionInbound 값을 설정하더라도 이 기능은 활성화되지 않습니다. /status를 입력하고 Peer address 행을 찾으십시오. 해당 행에는 uds:로 시작하는 이 세션의 고유 수신함 주소가 포함되어 있습니다.

구형 빌드를 사용하는 VPS 사용자에게는 한 가지 함정이 있습니다. v2.1.248 이전에는 동일 머신 내 메시징 기능이 기능 플래그 가져오기(feature-flag fetching)에 의존했습니다. 여러 개인정보 보호 변수가 이 가져오기 기능을 차단하며, 이로 인해 해당 기능이 기본적으로 비활성화 상태로 유지되었습니다. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_GROWTHBOOK 변수가 모두 이러한 동작을 수행합니다. 사용자가 새로운 서버를 강화하기 위해 이 변수들을 ~/.bashrc에 붙여넣은 뒤, 왜 /list-agents이 존재하지 않는지 의문을 갖는 경우가 많습니다. v2.1.248부터는 가져오기 기능이 꺼져 있어도 동일 머신 내 세션 간 메시징이 작동하므로, 업데이트를 수행하는 것이 가장 깔끔한 해결책입니다. 이 변수들은 여전히 이 머신 외부의 세션에는 영향을 미칩니다. 가져오기 기능이 꺼져 있으면 Claude는 Remote Control이 사용 가능한 경우에만 해당 세션에 도달할 수 있는데, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC과 DISABLE_GROWTHBOOK는 Remote Control을 사용할 수 없게 만듭니다. 동일한 값이 설정 파일의 env 맵이나 관리형 설정에서 전달될 수 있으므로, 먼저 셸 환경을 확인하십시오.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

구형 빌드를 사용하는 경우, 출력되는 변수를 모두 해제(unset)하십시오. DISABLE_TELEMETRY와 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC의 경우, 0이라는 문자열을 포함하여 비어 있지 않은 모든 값이 해당 기능을 활성화합니다. 따라서 DISABLE_TELEMETRY=0은 겉보기와 다르게 동작합니다. 기능을 끄려면 변수를 해제하거나 빈 문자열로 설정해야 합니다.

세션에 이름을 지정하십시오. 그렇지 않으면 Claude가 세션을 식별할 수 없습니다

Claude는 세션 이름을 통해 메시지를 전달합니다. 세션을 시작할 때 이름을 설정하십시오:

claude --name builder-api

실행 중인 세션 내부에서 /rename을 사용하여 이름을 설정할 수도 있습니다. 이름을 지정하지 않으면 Claude Code는 작업 디렉터리의 폴더 이름을 기반으로 이름을 생성합니다(예: myapp-3f). 세션이 하나일 때는 괜찮지만, 네 개가 되면 혼란스러워지며 두 세션의 이름이 같아질 수도 있습니다. 세션이 Remote Control에 연결된 경우가 아니라면, /list-agents 출력은 각 로컬 세션의 작업 디렉터리를 보여주므로 이름이 같은 세션을 구분할 수 있습니다. 또한 Claude 자체 목록은 이름이 충돌할 경우 주소에 짧은 식별자를 추가합니다. 직접 이름을 지정하는 것이 식별자를 읽는 것보다 효율적입니다. 직접 선택한 이름은 @ 자동 완성 기능을 유용하게 만듭니다. v2.1.232 버전부터는 프롬프트에 @builder를 입력하고 세션을 선택하면 Claude에게 정확히 어떤 세션을 의미하는지 전달할 수 있습니다.

재현 가능한 2개 세션 tmux 레이아웃

이 구성은 하나의 저장소에 대해 빌더 세션과 리뷰어 세션을 각각 운영하는 방식입니다. 리뷰어는 별도의 git worktree에서 작업하므로 두 세션이 동일한 파일을 수정하는 일은 없습니다. git worktree add와 HEAD를 조합하면 분리된 체크아웃이 생성되는데, 이는 커밋보다는 읽기 작업을 수행하는 세션에 적합합니다. 두 세션은 서로 다른 역할을 수행하므로 리뷰어에게 고유한 출력 스타일을 지정하는 것이 좋습니다. 이를 통해 세션의 시스템 프롬프트를 변경하면, 일회성 지시사항과 달리 모든 대화 턴에서 일관된 설정을 유지할 수 있습니다.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b를 입력한 뒤 w을 누르면 창 이름 목록이 표시되어 원하는 창을 선택할 수 있습니다. 빌더 창에서 /list-agents을 실행하십시오. 그러면 작업 디렉터리 ~/src/api-review가 포함된 reviewer-api이 나타나야 합니다. 만약 보이지 않는다면 리뷰어 세션이 시작되지 않았거나 다음 섹션에서 다룰 두 가지 문제 중 하나가 발생한 것입니다. 그런 다음 평이한 언어로 작업을 전달하십시오.

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude가 요약을 작성하여 전송합니다. 사용자가 메시지 본문을 직접 작성할 필요는 없으며, Claude가 보내는 내용은 상황에 따라 달라집니다. 리뷰어 창에는 발신자 이름과 텍스트의 첫 줄이 포함된 › Message from @builder-api: …과 같은 흐릿한 한 줄 미리보기가 나타납니다. 해당 세션이 유휴 상태라면 Claude는 즉시 새로운 턴을 시작합니다. 만약 작업이 진행 중이라면 메시지는 도구 호출 사이의 대기 시간까지 기다렸다가 표시되므로 실행 중인 명령이 중단되지 않습니다. Ctrl+O을 누르면 전체 텍스트가 포함된 대화 기록 뷰어가 열리며, 사용자가 확장 여부를 결정하기 전에도 Claude는 메시지 전체를 읽습니다. 빌더가 변경 사항을 작게 유지할수록 이 방식은 더 효과적입니다. 좁은 범위의 diff는 전달 과정을 간결하게 만들고, 리뷰어 세션이 한 번의 턴으로 검토를 마칠 수 있게 해주기 때문입니다. 이는 게으른 시니어 개발자의 기술이 강조하는 습관이기도 합니다.

단일 VPS 내에서의 세션 가시성

동일한 머신 내에서의 메시지 전달은 Anthropic 서버를 거치지 않습니다. 각 세션은 해당 머신의 파일 시스템 경로에 위치한 Unix 도메인 소켓인 자체 수신함 소켓을 바인딩하며, 세션이 소켓을 바인딩해야만 다른 세션의 목록에 나타납니다. 이로 인해 서버 환경에서 두 가지 결과가 발생합니다.

소켓은 운영체제의 사용자 계정으로 제한됩니다. root 사용자로 시작한 세션과 deploy 사용자로 시작한 세션은 동일한 tmux 서버 내에 나란히 있더라도 서로를 볼 수 없습니다. 한 사용자의 세션은 다른 사용자의 소켓에 접근할 수 없기 때문입니다. 두 세션을 모두 동일한 사용자로 실행하십시오.

컨테이너는 고유한 파일 시스템을 가집니다. Docker 내부의 세션과 호스트의 세션은 서로 접근할 수 없습니다. 동일한 컨테이너 내부의 두 세션은 정상적으로 메시지를 주고받을 수 있습니다. 일회용 VM에서 코딩 에이전트 실행하기와 같이 격리를 위해 컨테이너 내부에 에이전트를 유지하는 경우, 메시징은 컨테이너 내부에서만 작동하며 컨테이너 경계를 넘어 작동하지 않는다는 점을 유의하십시오.

다른 머신에서의 세션 및 클라우드 세션은 현재 세션이 Remote Control에 연결되어 있는 동안에만 목록에 나타나며, 다른 머신의 세션은 Remote Control로 표시됩니다. v2.1.225 버전부터는 Claude가 단순히 응답하는 것뿐만 아니라 대화를 먼저 시작할 수 있습니다. 해당 메시지는 Anthropic 서버를 통해 전달됩니다. Claude가 머신 외부로 메시지를 보낼 때 현재 세션이 Remote Control에 연결되어 있지 않더라도 메시지는 발송되지만, 회신 주소가 없으므로 상대방은 이에 응답할 수 없습니다.

메시지가 도착하지 않는 이유

일반적인 원인은 네트워크와 무관합니다. 수신 세션이 메시지를 어떻게 처리할지 결정하며, 전달하지 않기로 결정했을 가능성이 큽니다. 모든 수신 메시지는 전달됨, 보류됨(승인 전까지 전달되지 않고 대기), 거부됨(전달 없이 삭제) 중 하나의 결과로 끝납니다.

적용되는 crossSessionInbound 값이 없을 때, Claude Code는 두 세션의 권한 모드를 비교하여 메시지별로 결정합니다. 권한 확인 프롬프트를 우회하는 세션과 그렇지 않은 세션으로 분류합니다. auto, acceptEdits, dontAsk은 프롬프트가 발생하는 것으로 간주합니다. Plan 모드는 우회 권한을 사용할 수 있는 대화형 터미널 세션에서는 우회하는 것으로 간주합니다. 세션이 어떤 분류에 속하는지 확실하지 않다면 각 권한 모드의 실제 동작을 먼저 읽어보는 것이 좋습니다. auto 모드는 현재 대부분의 세션이 시작되는 기본값이며, 이 분류상 프롬프트가 발생하는 쪽에 속하기 때문입니다. 규칙은 다음과 같이 대칭적입니다.

• 권한 확인 프롬프트가 발생하는 수신 세션은 모든 메시지를 전달받습니다. 단, 발신 세션이 프롬프트를 우회한다고 식별된 경우에만 메시지를 보류합니다.
• 프롬프트를 우회하는 수신 세션은 모든 메시지를 사용자의 승인을 위해 보류합니다. 발신자 또한 우회 중일 때만 메시지를 전달합니다.

따라서 대부분의 사용자가 처음 구성하는 워크플로우가 의도대로 작동하지 않는 경우가 많습니다. 무인 실행을 위해 --permission-mode bypassPermissions로 빌더를 시작하고 리뷰어는 기본값으로 두면, 빌더가 보내는 모든 메시지는 아무도 보지 않는 승인 대화 상자에서 대기하게 됩니다. 해당 대화 상자는 dialogExpiry 기한(기본값 5m)이 지나면 닫히고 메시지는 삭제됩니다. 소켓 문제를 의심하기 전에 수신 세션 화면에서 대기 중인 승인 대화 상자가 있는지 확인하십시오.

세션이 메시지를 무인으로 처리하게 하려면 crossSessionInbound를 accept으로 설정하십시오. 설정 위치에 따라 적용 여부가 결정됩니다. Claude Code는 관리형 설정을 먼저 읽고, 그 다음 --settings 플래그, 마지막으로 사용자 설정을 읽어 가장 먼저 발견된 값을 적용합니다. 프로젝트 또는 로컬 설정의 값은 accept < hold < refuse 순서의 계층 구조에서 더 엄격할 때만 적용됩니다. .claude/settings.json의 accept은 가장 느슨한 설정이므로, 신뢰할 수 있는 소스에서 값이 설정된 경우 무시됩니다. ~/.claude/settings.json에 설정하거나 특정 세션에 대해 전달하십시오. v2.1.232 버전부터는 /config 행의 Messages from your other sessions 항목을 통해 동일한 사용자 설정을 자동으로 작성할 수 있습니다.

claude --name runner --settings '{"crossSessionInbound":"accept"}'

헤드리스 claude -p 워커는 대화형 세션처럼 수신 소켓을 바인딩하고 목록에 나타나지만, 승인 대화 상자를 표시할 수 없습니다. Claude Code는 해당 세션에서 메시지를 동일한 dialogExpiry 기한(기본값 5분) 동안 보류하며, 해당 시간 내에 모드나 설정 변경으로 허용되면 전달하고, 그렇지 않으면 삭제한 뒤 도달 가능한 발신자에게 만료되었음을 보고합니다. 위에서 언급한 --settings 행은 이러한 워커가 메시지를 처리하도록 허용하는 방법입니다. bare 모드로 시작된 세션은 소켓을 전혀 바인딩하지 않으므로 메시지를 수신할 수도 없고 목록에 나타날 수도 없습니다.

핸드오프가 교착 상태에 빠지는 경우

메시지 루프는 시스템이 자동으로 처리합니다. Claude Code는 발신자별로 반복 메시지에 대한 속도 제한(rate-limit)을 적용하고, 짧은 시간 내에 도착하는 동일한 메시지는 삭제하며, 읽기 대기 중인 메시지를 세션당 50개로 제한하므로 두 세션이 영원히 핑퐁(ping-pong)을 주고받을 수 없습니다. 보류 중인 메시지는 100개로 제한되며, 이를 초과하면 가장 오래된 메시지부터 삭제됩니다. v2.1.238 버전부터는 수신자의 받은 편지함에서 메시지가 삭제될 경우 발신 세션에 그 이유와 함께 알림이 전달되며, 동일한 세션을 계속 통과하는 릴레이 체인은 차단됩니다.

실제로 발생하는 문제는 루프보다는 핸드오프 과정에서 발생하는 더 조용한 형태의 실패입니다. 세션 A가 작업을 계속하기 위해 필요한 질문을 세션 B에 던진 뒤 유휴 상태가 됩니다. 이때 B가 메시지를 보류하거나, B가 긴 작업을 수행 중이거나, 혹은 B가 A가 의도하지 않은 질문에 답변하는 상황이 발생합니다. A는 대기합니다. 한 시간 뒤 돌아와 보면 두 세션 모두 유휴 상태이며 작업은 완료되지 않았습니다.

답변이 필요 없는 방식으로 핸드오프를 작성하십시오. 좋은 메시지는 사실이나 결정 사항을 전달합니다. 즉, 무엇이 변경되었고 결과가 무엇인지 명시합니다. 나쁜 메시지는 다른 세션에 허락을 구하거나 발신자가 차단된 상태에서 답변을 요구합니다. Claude는 자신의 권한 설정으로 차단된 작업을 다른 세션에 요청하지 말고 사용자에게 직접 라우팅하도록 이미 지시받았습니다. 이 규칙을 직접 확장하십시오. 답변 없이는 세션이 진행될 수 없다면, 답변을 제공해야 할 주체는 바로 사용자입니다. 세션이 맥락을 잃으면 모호한 메시지를 작성하게 되므로 맥락 관리 또한 중요합니다. Claude Code에서의 맥락 관리에서 이 부분을 다룹니다.

수신 메시지를 신뢰할 수 없는 입력으로 처리하기

Claude Code는 수신하는 Claude에게 해당 메시지가 사용자가 아닌 다른 세션에서 왔음을 알리고, 해당 메시지가 수행할 수 있는 작업을 제한합니다. 이러한 강제 조치는 모델의 순응 여부가 아니라 모델을 감싸고 있는 프로그램 수준에서 이루어지며, 이것이 바로 에이전트 하니스가 제공하는 실질적인 차이점입니다. 다른 세션에서 보낸 동의는 사용자의 동의가 아니므로, 메시지는 사용자를 대신하여 대기 중인 권한 프롬프트를 승인할 수 없습니다. 또한 다른 세션의 요청이라는 이유만으로 권한 설정, CLAUDE.md 또는 기타 구성을 변경할 수도 없습니다. /compact와 같은 텍스트 내부의 슬래시 명령은 일반 텍스트로 전달되며 절대 실행되지 않습니다. 메시지에 따른 작업 수행 시 수신 세션에 없는 권한이 필요하다면, 다른 작업과 마찬가지로 동일한 프롬프트가 표시됩니다. 송신 세션이 자동 모드에서 실행 중일 때, Claude Code가 메시지를 전달하기 전에 해당 세션의 분류기가 각 메시지를 검토하며, 차단된 메시지는 수신자에게 도달하지 않습니다. 이러한 제한은 허용적인 모드에서도 유지되므로, 우회하는 세션은 인바운드 메시지를 신뢰하는 대신 기본적으로 보류합니다.

이는 권한에 관한 내용이며 콘텐츠는 포함하지 않습니다. 송신 세션은 풀 리퀘스트 설명, 웹 페이지, 의존성 README 또는 낯선 사람이 작성한 이슈 댓글을 읽었을 수 있으며, 읽은 내용은 해당 세션이 다른 세션으로 작성하는 텍스트에 영향을 줄 수 있습니다. 메시지는 데이터입니다. 외부에서 세션으로 들어온 다른 모든 텍스트와 마찬가지로 의심해야 합니다. 이는 AI 에이전트에서 비밀 유지하기에서 설명하는 원칙과 같습니다. 신뢰 경계를 넘어온 모든 것은 잘못되었을 수 있다고 가정하고, 절대 스스로 권한을 부여하도록 두지 마십시오.

이러한 상황을 줄이려면 두 가지 제어 기능을 사용할 수 있습니다. crossSessionInbound을 refuse로 설정하면 인바운드 피어 메시지를 전달하지 않고 폐기합니다. 프로젝트 설정이나 로컬 설정에서 이 값을 지정하면 가장 엄격한 우선순위가 적용되므로 다른 모든 소스보다 우선합니다. 이 세션에서 메시지를 보내거나 나열하는 것을 중지하려면 SendMessage 및 ListAgents에 대한 권한 거부 규칙을 추가하십시오. 두 규칙 모두 지정자 없이 도구 이름만 작성해야 합니다. isolatePeerMachines을 true로 설정하면 메시지가 이 머신 외부의 세션에 도달하기 전에 사용자의 명시적인 승인이 필요하며, 이 승인은 bypassPermissions 모드에서도 필수입니다.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

SendMessage를 거부하면 서브 에이전트로의 메시지 전송도 제거됩니다. 동일한 도구가 두 작업 모두를 수행하기 때문입니다. 거부 중인 세션은 자체 /status나 다른 세션의 목록에 눈에 띄는 변화를 보이지 않으므로, 화면이 아닌 세션 구성을 통해 설정을 확인하십시오.

브리지와 공유 메모리 MCP 서버

비슷한 시기에 인접한 기능을 제공하는 서드파티 프로젝트도 여러 개 등장했다. 실행 중인 에이전트 사이에서 텍스트를 전달하는 로컬 에이전트 간 브리지와, 여러 에이전트가 하나의 공유 저장소를 읽고 쓸 수 있게 하는 MCP (model context protocol) 서버가 이에 해당한다. 이를 경쟁 제품이 아니라 다른 형태의 도구로 판단해야 하며, 설치 명령을 실행하기 전에 해당 프로젝트의 README에서 명령을 확인해야 한다. 메시징은 송신자가 수신자의 턴에 텍스트를 넣으므로 push 방식이다. 공유 저장소는 아무도 중단되지 않고 세션이 다음에 확인할 때 메모를 보므로 pull 방식이다. 천천히 변하는 상태에는 pull 방식이 더 안정적이며, 세션이 실제로 확인할 때만 작동한다.

이 방식을 선택한다면 기능 목록보다 프로세스에 대해 질문해야 한다. 서버가 어떤 사용자로 실행되며 시스템에서 무엇을 읽을 수 있는가. VPS에서 MCP 서버 실행하기에서 해당 설정을 다룬다. 리포지토리 간 에이전트 기술 공유하기에서는 세션 사이에 공유하려는 것이 실시간 상태가 아니라 지침인 단순한 경우를 다룬다. 이 방법을 사용하면 그렇지 않을 때 보내야 하는 메시지를 많이 줄일 수 있다. 전체적인 내용은 VPS에서 코딩 에이전트 실행하기에서 시작하면 된다.

FAQ

왜 세션에서 /list-agents 명령을 인식하지 못합니까?

해당 세션은 세션 간 메시징 기능을 지원하지 않습니다. 먼저 claude --version을 확인하십시오. 이 기능은 macOS 및 Linux에서는 2.1.224 버전 이상, Windows 네이티브 환경에서는 2.1.234 버전 이상, Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, Microsoft Foundry에서는 2.1.248 버전 이상이 필요합니다. 2.1.248 미만 버전에서는 셸에서 DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 또는 DISABLE_GROWTHBOOK이 설정되어 있는지 확인하십시오. 이 설정들은 구형 빌드에서 메시징에 필요한 기능 플래그 가져오기를 비활성화합니다. 2.1.248 이상으로 업데이트하면 동일한 머신 내 세션에 대해 이러한 의존성이 제거됩니다.

왜 다른 세션으로 보낸 메시지가 도착하지 않았습니까?

/list-agents이 정상 작동한다면 메시징 기능은 켜져 있으나 다른 특정 요인이 메시지를 차단한 것입니다. 가장 흔한 원인은 권한 모드입니다. 권한 확인 절차를 우회하는 세션은 발신자도 우회 설정을 하지 않은 경우 모든 수신 메시지를 사용자의 승인 대기 상태로 둡니다. 이 승인 대화 상자는 dialogExpiry 기한(기본값 5분)이 지나면 사라집니다. 수신 세션에서 승인 대기 중인 대화 상자가 있는지 확인하십시오. 이를 해결하려면 ~/.claude/settings.json에서 crossSessionInbound을 accept로 설정하거나 --settings을 통해 전달하십시오. 프로젝트 설정이나 로컬 설정에 있는 accept은 더 느슨한 값으로 간주되어 무시되기 때문입니다.

Docker 내부의 Claude Code 세션이 호스트의 세션과 메시지를 주고받을 수 있습니까?

아니요. 각 세션의 수신함은 해당 머신의 파일 시스템에 있는 소켓이며, 컨테이너는 고유한 파일 시스템을 가집니다. 따라서 컨테이너 내부의 세션과 호스트의 세션은 서로 접근할 수 없습니다. 동일한 컨테이너 내부의 두 세션은 정상적으로 메시지를 주고받을 수 있습니다. 이와 유사한 원리로 root로 실행 중인 세션과 일반 사용자 권한으로 실행 중인 세션도 서로 통신할 수 없습니다. 소켓은 해당 소켓을 소유한 운영체제 사용자에게만 접근이 제한되기 때문입니다.

다른 Claude Code 세션에서 온 메시지는 안전하게 처리할 수 있습니까?

해당 텍스트를 신뢰할 수 없는 입력으로 간주하십시오. 발신 세션이 웹 페이지, README 또는 타인이 작성한 이슈 댓글을 읽었을 수 있기 때문입니다. Claude Code는 메시지가 스스로 동작하지 않도록 이미 제한하고 있습니다. 대기 중인 권한 승인 프롬프트를 자동으로 승인할 수 없으며, 요청에 따라 권한 설정이나 CLAUDE.md를 변경할 수 없습니다. 또한 텍스트 내의 슬래시 명령은 일반 텍스트로 전달될 뿐 실행되지 않습니다. 이러한 보호 조치는 권한에 관한 것이며 판단에 관한 것은 아니므로, 수신 세션에 작업을 지시하기 전에 도착한 내용을 직접 읽어보시기 바랍니다.

세션 간 메시징을 사용하면 내 코드가 Anthropic으로 전송됩니까?

동일한 머신 내의 두 세션 간에는 전송되지 않습니다. 메시지는 해당 머신의 세션별 소켓을 통해 이동하며 Anthropic 서버를 거치지 않습니다. 또한 Claude가 작성한 텍스트만 전송되며 대화 기록이나 파일은 절대 전송되지 않습니다. 다른 머신에 있는 세션이나 클라우드 세션으로 보내는 메시지는 Anthropic 서버를 통과합니다. v2.1.225부터는 Claude가 이러한 교환을 시작하거나 응답할 수 있습니다. 머신 외부로 데이터가 나가기 전에 승인을 요구하려면 isolatePeerMachines을 true로 설정하십시오.