포그라운드 데몬 연결을 확인한 뒤에 이 가이드를 사용하세요. 명령은 지원되는 상주 백엔드, 즉 Claude Code, Codex, Kiro, Pi에 적용됩니다.

## 데몬 백엔드를 0.20.0으로 업그레이드

[업데이트 명령](/ko/reference/cli/#cli와-플러그인-업그레이드)으로 Chorus CLI를 갱신하고 진행 중인 작업에 지장이 없을 때 데몬을 재시작하세요. 호스트 CLI는 별도로 업데이트합니다. 데몬이 처음 작업을 시작하기 전에 백엔드별 요구사항을 확인하세요.

- [Codex App Server](/ko/reference/agents/codex/#0200의-데몬-동작): codex-cli 0.157.1로 검증했습니다. 데몬 `args`는 모델 옵션과 허용된 설정만 받습니다. `--chorus-only`에서는 필요한 MCP 도구 허용을 Codex 설정에서 확인하세요.
- [Claude Code stream-json](/ko/reference/agents/claude-code/#0200의-데몬-동작): Claude Code 2.1.283 및 2.1.284로 검증했습니다. 중단할 때는 먼저 프로토콜 수준의 중단을 사용하며, 백그라운드에서 생긴 질문은 반드시 Chorus 댓글이나 요구사항 구체화로 처리해야 합니다.
- [Pi RPC](/ko/reference/agents/pi/#0200의-데몬-동작): Pi 0.85.0 이상이 필요합니다(0.85.1로 검증). `--plugins`는 Chorus 패키지를 갱신하지만 Pi 자체는 업그레이드하지 않습니다.

## 데몬이 접근할 수 있는 범위 정하기

각 `--cwd`는 하나의 작업 디렉터리를 Chorus에서 별개의 대상으로 등록합니다.

```sh
chorus daemon \
  --agent claude-code \
  --cwd ~/work/project-a \
  --cwd ~/work/project-b \
  --chorus-only
```

`--cwd`가 없으면 Chorus는 명령을 시작한 디렉터리를 사용합니다. 반복 지정할 수 있는 `--browse-root` 옵션은 사용자가 더 넓은 루트 아래에서 디렉터리를 골라야 할 때만 사용하세요. browse root는 탐색을 허용할 뿐, 그 아래의 모든 디렉터리를 온라인 연결로 등록하지는 않습니다.

프로젝트의 에이전트에 대해 [작업 디렉터리를 고정](/ko/guides/create-a-project/)할 때, 그 경로는 이 데몬이 제공하는 디렉터리여야 합니다. 경로를 이 데몬의 `cwds` 집합에 포함해 고정된 디렉터리가 온라인 연결로 연결되게 하세요.

:::caution[파일 시스템 접근을 제한하세요]
에이전트가 읽고 수정하도록 허용된 디렉터리만 등록하세요. 원격으로 시작된 에이전트는 데몬을 실행하는 사용자의 파일 시스템과 도구 권한을 그대로 받습니다.
:::

## `daemon.json` 구성하기

데몬은 설정을 `~/.chorus/daemon.json`에서 읽습니다. 일반적인 단일 에이전트 구성에서는 에이전트 인증 정보와 런타임 옵션을 함께 담은 평면 JSON 객체 하나입니다. 하나의 데몬으로 여러 에이전트를 서비스하려면 대신 `agents` 배열에 에이전트를 나열합니다([하나의 데몬에서 여러 에이전트 실행하기](#하나의-데몬에서-여러-에이전트-실행하기) 참조). 어느 형식이든 파일은 `0600`(소유자만 읽기/쓰기) 권한으로 원자적으로 기록되므로, 쓰기 도중 크래시가 나도 잘린 파일이 남지 않습니다. 다른 파일을 사용하려면 `CHORUS_DAEMON_CONFIG_PATH`를 설정하세요. 이 경우 CLI와 데몬 서비스에 같은 값을 설정해야 합니다. 셸에서 export해도 이미 실행 중인 서비스에는 반영되지 않습니다.

### 필드

| 필드 | 타입 | 의미 |
| --- | --- | --- |
| `url` | string | Chorus 서버 URL. |
| `apiKey` | string | 에이전트 API 키(`cho_…`). |
| `agentUuid` | string | 인증된 에이전트 UUID(참고용). |
| `agentName` | string | 인증된 에이전트 이름(참고용). |
| `cwds` | string[] | 이 데몬이 제공하는 작업 디렉터리. 각 경로는 하나의 독립된 온라인 연결입니다. |
| `browseRoots` | string[] | 원격 작업 디렉터리 탐색에 노출하는 루트. browse root는 연결을 만들지 않습니다. |
| `agent` | string | 깨울 로컬 백엔드: `"claude-code"`, `"codex"`, `"kiro"`, `"pi"`, `"dsh"`. |
| `sigintTimeoutMs` | number | 중단 후 강제 종료까지의 유예 시간(밀리초). Claude Code, Codex, Pi는 먼저 프로토콜 중단을 보냅니다. 기본값 `10000`. |
| `agents` | object[] | *선택.* 하나의 데몬으로 여러 독립 에이전트를 서비스합니다. 각 항목은 공유 런타임 기본값을 재정의할 수 있지만 `args`와 `env`는 상속되지 않습니다. [하나의 데몬에서 여러 에이전트 실행하기](#하나의-데몬에서-여러-에이전트-실행하기) 참조. |

`chorus login`과 `chorus daemon install`을 실행한 직후의 최소 파일입니다.

```json
{
  "url": "https://chorus.example.com",
  "apiKey": "cho_REDACTED",
  "agentUuid": "8a1c…",
  "agentName": "Build Agent",
  "cwds": ["/home/demo/work/project-a"],
  "browseRoots": ["/home/demo/work"],
  "agent": "claude-code",
  "sigintTimeoutMs": 10000
}
```

### 파일은 어떻게 만들어지는가

- 보통은 `chorus agents add`가 이 파일을 처음 만듭니다. 구성된 각 에이전트의 인증 정보를 검증하고 `agents` 배열의 항목으로 씁니다. [에이전트 런타임 연결](/ko/guides/operator-onboarding/)을 참고하세요.
- `chorus login`은 URL과 키를 검증한 뒤, 단일 평면 에이전트에 대해 `url`, `apiKey`, `agentUuid`, `agentName`을 씁니다.
- `chorus daemon install`은 추가로 `cwds`, `browseRoots`, `agent`를 씁니다(아직 설정되지 않았다면 제공할 디렉터리와 백엔드를 묻습니다).
- 터미널에서 `chorus daemon`을 처음 실행하면 빠진 인증 정보를 대화형으로 입력받아 기록합니다.

### 파일은 어떻게 갱신되는가

파일에 쓰는 모든 명령은 **얕은 병합**을 수행합니다. 새 필드는 디스크에 이미 있는 내용 위에 병합되고, 관련 없는 필드는 그대로 유지됩니다. `chorus login`을 다시 실행하면 `cwds`, `agent`, `sigintTimeoutMs`를 지우지 않고 인증 정보만 새로 고칩니다. `chorus daemon install`을 다시 실행하면 인증 정보를 버리지 않고 제공하는 집합을 갱신합니다. 파일이 없거나 손상되면 빈 객체로 취급되므로, 다시 로그인하면 실패하지 않고 항상 유효한 파일이 만들어집니다.

### 필드, 플래그, 환경 변수

아래 런타임 옵션은 세 가지 방법으로 줄 수 있습니다. 우선순위는 플래그, 그다음 환경 변수, 마지막이 `daemon.json`이므로, 일회성 플래그나 환경 변수 재정의를 파일에 쓸 필요가 없습니다.

| 대상 | `daemon.json` 필드 | CLI 플래그 | 환경 변수 |
| --- | --- | --- | --- |
| 서버 URL | `url` | `--url` | `CHORUS_URL` |
| API 키 | `apiKey` | `--api-key` | `CHORUS_API_KEY` |
| 작업 디렉터리 | `cwds` | `--cwd`(반복 가능) | `CHORUS_DAEMON_CWDS` |
| browse root | `browseRoots` | `--browse-root`(반복 가능) | `CHORUS_DAEMON_BROWSE_ROOTS` |
| 백엔드 | `agent` | `--agent` | `CHORUS_AGENT` |
| SIGINT 유예 | `sigintTimeoutMs` | `--sigint-timeout` | `CHORUS_DAEMON_SIGINT_TIMEOUT` |
| 권한 모드 | *(저장되지 않음)* | `--yolo` / `--chorus-only` | `CHORUS_YOLO` / `CHORUS_CHORUS_ONLY` |

권한 모드는 의도적으로 `daemon.json`에 저장되지 않습니다. 시작할 때 `--chorus-only`를 전달하거나 `CHORUS_CHORUS_ONLY=1`을 설정하세요. 설치된 서비스는 `--chorus-only`를 파일이 아니라 그 유닛에 담습니다.

## 하나의 데몬에서 여러 에이전트 실행하기

하나의 `chorus daemon` 프로세스는 **여러 개의 완전히 독립된 에이전트를 동시에 서비스**할 수 있습니다. 페르소나, 권한, 계정, 심지어 백엔드가 서로 달라도 되므로 에이전트마다 별도의 데몬을 돌릴 필요가 없습니다. 에이전트를 `agents` 배열에 나열하며, 각 항목이 하나의 에이전트입니다.

```json
{
  "url": "https://chorus.example.com",
  "sigintTimeoutMs": 8000,
  "agents": [
    { "apiKey": "cho_alpha", "agentType": "claude-code", "cwds": ["/home/demo/project-a"] },
    { "apiKey": "cho_beta", "agentType": "kiro", "cwds": ["/home/demo/project-b"], "permissionMode": "chorus" }
  ]
}
```

`url`, `sigintTimeoutMs` 같은 공유 런타임 설정이 기본값을 제공하며, 에이전트 자체 값으로 재정의할 수 있습니다. `args`와 `env`는 에이전트별 설정이며 공유 기본값이 아닙니다. 각 에이전트는 고유한 신원(키로 결정), 고유한 연결(`cwds`마다 하나), 고유한 깨우기 큐, 고유한 백엔드를 가집니다. 따라서 에이전트마다 독립적으로 깨어나 실행되며, 한 에이전트가 실패해도 다른 에이전트에는 영향이 없습니다. 서버에서는 각 에이전트가 에이전트·호스트·디렉터리 단위로 구분되어 **설정 → 에이전트**(Settings → Agents)에 별도의 연결로 표시됩니다. 여러 에이전트가 같은 작업 디렉터리를 공유할 수도 있지만 데몬이 작업을 직렬화하지 않으므로, 하나의 git 트리 안에서 서로 충돌하는 작업을 동시에 하지 마세요(별도의 브랜치나 worktree를 사용하세요).

:::note[하위 호환]
`agents` 배열이 없으면 최상위의 평면 `url` / `apiKey` / `cwds`가 정확히 하나의 에이전트로 취급되므로, 기존의 단일 에이전트 설치는 변경 없이 그대로 동작합니다.
:::

### 에이전트별 필드

| 필드 | 의미 |
| --- | --- |
| `apiKey`(필수) | 에이전트의 `cho_` 키. 이 키로 에이전트의 신원이 정해집니다. |
| `url` | Chorus 서버(에이전트마다 다를 수 있음 — 다른 서버나 워크스페이스). |
| `agentType` | `claude-code`, `codex`, `kiro`, `pi`(백엔드는 혼합 가능). |
| `cwds` | 이 에이전트가 제공하는 작업 디렉터리(각각 하나의 연결). |
| `permissionMode` | `yolo` 또는 `chorus`. |
| `maxConcurrency` | 이 에이전트 자신의 깨우기 동시 실행 상한(기본값 `4`). |
| `sigintTimeoutMs` | 중단 후 강제 종료까지의 유예 시간(밀리초). |
| `browseRoots` | 디렉터리 탐색 허용 목록. |
| `args` | 백엔드 CLI에 전달할 추가 인수의 문자열 배열(선택). 기본값 `[]`. [에이전트의 모델, 사고 수준, 환경 변수 설정하기](#에이전트의-모델-사고-수준-환경-변수-설정하기)를 참고하세요. |
| `env` | 환경 변수 이름을 문자열 값에 매핑하는 객체(선택). 기본값 `{}`. |

### 에이전트의 모델, 사고 수준, 환경 변수 설정하기

`~/.chorus/daemon.json`의 대상 항목에 필드를 추가하세요. 이 Pi 예제는 예시용 인증 정보와 민감하지 않은 환경 변수 값을 사용합니다. URL, 키, 모델은 사용 환경에 맞는 값으로 바꾸고, 다른 에이전트를 덮어쓰지 않도록 기존 파일에 병합하세요.

```json
{
  "url": "https://chorus.example.com",
  "agents": [
    {
      "agentName": "pi-worker",
      "apiKey": "cho_REDACTED",
      "agentType": "pi",
      "args": ["--model", "anthropic/claude-sonnet-4-6", "--thinking", "high"],
      "env": { "PROVIDER_REGION": "us-east-1" }
    }
  ]
}
```

모델은 예시이며 Chorus 기본값이 아닙니다. 백엔드가 지원하는 플래그와 값을 사용하세요. 별도의 `model`이나 `thinking` 필드는 없습니다. 데몬의 깨우기와 `chorus agents run --name pi-worker` 모두 이 항목을 사용합니다. `offline` 에이전트는 이 경우에도 깨울 수 없습니다.

- **전역 상속 없음**: 비어 있지 않은 `agents` 배열이 있으면 최상위 `args` 또는 `env`는 오류가 됩니다. 해당하는 각 항목으로 옮기세요. 다른 에이전트나 셸에는 영향이 없습니다.
- **값 그대로 전달**: `args`의 각 요소는 인수 하나이며, 셸용 따옴표를 따로 붙이지 않습니다. `$HOME`, `${TOKEN}`, 셸 명령은 확장되지 않습니다. Chorus는 dotenv 로딩, 보간, 비밀 조회 또는 env 값의 특별 처리를 추가하지 않습니다. `env`는 자식 프로세스가 상속한 환경을 덮어쓰지만, Chorus가 관리하는 제어 항목이 여전히 우선합니다. 환경 변수 이름은 Windows에서는 대소문자를 구분하지 않고 POSIX에서는 구분합니다.
- **검증**: `null`, 문자열이 아닌 인수나 값, NUL 문자, `[A-Za-z_][A-Za-z0-9_]*`에 맞지 않는 변수 이름은 실행 전에 거부됩니다. 빈 문자열 값은 유효합니다. 위치 인수로 된 프롬프트나 하위 명령 대신 옵션을 사용하세요. 알 수 없는 옵션은 백엔드가 지원한다면 `"--future=value"` 형식으로 쓰세요. `"--future", "value"`는 모호하므로 거부됩니다.
- **보호된 제어 항목**: 영구 인수는 알려진 세션/재개, 프롬프트, 전송/출력, 작업 디렉터리, 관리형 MCP, 권한 제어를 변경할 수 없습니다. 도움말/버전처럼 정보만 출력하고 종료하는 옵션, 단독 `--`, 표준 입력 표시자 `-`도 금지됩니다. 모든 `CHORUS_*` 환경 변수 이름과 중첩 Claude 컨텍스트 이름 `CLAUDECODE` / `CLAUDE_CODE_ENTRYPOINT`는 대소문자와 무관하게 예약되어 있습니다. 이를 설정하면 조용히 무시되지 않고 오류가 발생합니다. 대신 전용 Chorus 설정이나 명시적인 포그라운드 패스스루를 사용하세요.
- **Windows 명령 래퍼**: `.cmd`/`.bat` 실행은 구성된 빈 인수와 공백, 따옴표, 명령 메타 문자가 포함된 인수를 거부합니다. 이런 값에는 네이티브 실행 파일을 사용하세요. 래퍼를 거치는 명시적 포그라운드 패스스루는 셸에서 안전하다고 보장되지 않습니다.

Env에는 평문 제공자 인증 정보가 들어갈 수 있습니다. 파일을 보호하고(POSIX에서 `chmod 600 ~/.chorus/daemon.json`) 비밀을 커밋하지 마세요. Chorus는 검증/실행 메시지에 구성 값을 표시하지 않지만, 자식 프로그램이나 OS 수준의 검사로 노출될 수 있습니다. 암호화나 비밀 저장소(vault) 기능은 없습니다. `CODEX_HOME`이나 `PI_CODING_AGENT_DIR` 같은 사용자 지정 홈을 설정하면 그곳에도 Chorus 통합을 구성하세요.

**변경 적용**: `chorus daemon restart`를 실행하세요. 데몬은 이 설정을 시작할 때 읽으며, 깨울 때마다 다시 읽지는 않습니다. 파일을 편집해도 실행 중인 자식 프로세스는 바뀌지 않고, 재시작하기 전까지는 이후의 깨우기에도 이전 설정이 사용됩니다. 새로 실행하는 `chorus agents run`은 매번 프로필을 다시 읽지만, 이미 실행 중인 자식 프로세스에는 영향을 주지 않습니다. `args`/`env`를 제거하면 사용자 지정 전 동작으로 돌아갑니다.

**기존 평면 파일**: 비어 있지 않은 `agents` 배열이 없으면 최상위 `args`/`env`는 단일 데몬 에이전트에 적용됩니다. 포그라운드에서 에이전트를 선택하려면 `agents[]`가 필요합니다. 설정을 공유하려면 평면 URL, 키, 식별 정보, `args`, `env`를 항목으로 옮기고 `agent`를 `agentType`으로 바꾸세요. `chorus agents add` 또는 `chorus login --add`로 에이전트를 추가할 때도 기존 평면 인증 정보 프로필과 args/env가 `agents[0]`로 옮겨지고 해당 최상위 키는 제거됩니다. 키가 없는 불완전한 평면 프로필은 먼저 완성하거나 수동으로 변환해야 합니다.

일회성 재정의와 하위 명령의 정확한 규칙은 [CLI 참고 문서](/ko/reference/cli/)를 확인하세요.

### 다른 에이전트 추가하기

- **`chorus login --add`** 명령은 새 키를 검증하고 다른 에이전트로 추가합니다. 평면 파일에서 처음 `--add`를 사용하면 기존 인증 정보를 `agents[0]`로 옮기고 새 키를 `agents[1]`로 추가합니다. 중복된 키는 거부되며, 기존 에이전트를 덮어쓰지 않습니다.
- **`chorus daemon install --add`** 명령은 설치 마법사를 반복 실행하여 한 번에 여러 에이전트를 추가할 수 있습니다(터미널만).
- `~/.chorus/daemon.json`을 **직접 편집**하는 방법도 항상 지원됩니다.

파일을 편집한 뒤에는 데몬을 재시작하고(`chorus daemon restart`), **설정 → 에이전트**(Settings → Agents)에서 각 에이전트가 나타나는지 확인하세요.

### 각 백엔드는 자신의 키를 어떻게 받는가

각 에이전트는 자신의 키로 인증하지만, 그 키가 깨어난 하위 프로세스에 *어떻게* 전달되는지는 백엔드에 따라 다릅니다.

- **Claude Code** — 자동. 데몬이 깨울 때마다 해당 에이전트의 URL과 키를 담은 MCP 설정을 작성합니다. 따로 구성할 것은 없습니다.
- **Kiro** — 환경 변수를 통해 자동. 설치된 `mcp.json`은 `${CHORUS_URL}`과 `${env:CHORUS_API_KEY}`를 참조하고, 데몬이 깨울 때마다 이를 내보내므로, 각 Kiro 에이전트는 자신의 키로 인증합니다.
- **Codex** — 환경 변수를 통해 자동. `chorus agents add`는 Codex 설정 파일에 키를 저장하지 않는 방식으로 Codex를 구성합니다. `CHORUS_URL` / `CHORUS_API_KEY` / `CHORUS_AGENT_PROFILE`를 `~/.codex/.env`(Codex가 시작할 때 로드함)에 쓰고 `config.toml`에 `bearer_token_env_var = "CHORUS_API_KEY"`를 설정하므로, Codex는 파일에 기록된 키가 아니라 환경 변수에서 키를 읽습니다. 데몬이 깨울 때마다 각 에이전트의 키를 주입하므로, 하나의 데몬에 있는 여러 Codex 에이전트가 각자 자신의 신원으로 인증합니다.
- **Pi** — 환경 변수를 통해 자동. 데몬은 깨울 때마다 각 에이전트의 `CHORUS_URL` / `CHORUS_API_KEY` / `CHORUS_AGENT_PROFILE`를 깨운 Pi 세션으로 내보내고 `chorus-pi` 확장이 이를 읽으므로, 각 Pi 에이전트는 자신의 키로 인증합니다.

## Linux 서비스 설치하기

Linux에서는 확인된 구성을 사용자 서비스로 설치합니다.

```sh
chorus daemon install \
  --agent claude-code \
  --cwd ~/work/project-a \
  --chorus-only
```

설치 프로그램은 서비스를 즉시 시작하고, 사용자가 로그인할 때 시작되도록 구성합니다. 서비스가 저장된 인증 정보를 읽을 수 있도록 먼저 `chorus agents add`(또는 `chorus login`)를 실행하세요. 또는 `chorus agents add`에 `--daemon-autostart`를 전달하면 같은 단계에서 이 서비스를 설치할 수 있습니다.

:::note[왜 인증 정보가 파일에 담기는가]
`systemd --user` 유닛은 깨끗한 부팅 환경에서 시작하며, 셸에서 내보낸 `CHORUS_URL` / `CHORUS_API_KEY`를 상속하지 **않습니다**. 그래서 `chorus daemon install`은 유닛을 쓰기 전에 인증 정보를 해석·검증하고 `~/.chorus/daemon.json`(`0600`)에 저장합니다. 유닛은 파일 경로도 인증 정보도 참조하지 않으며, `HOME`만 설정해 데몬이 부팅 시 `~/.chorus/daemon.json`을 찾을 수 있게 합니다. 제공하는 `cwds`와 선택한 `agent`도 같은 파일에 저장되며, 유닛에 담기는 것은 `--chorus-only`뿐입니다.
:::

### 깨운 에이전트에 필요한 인증 정보 제공하기

데몬은 Chorus 연결(`CHORUS_URL`, `CHORUS_API_KEY`, `CHORUS_AGENT_PROFILE`)을 제공하지만 모델 제공자 인증 정보는 제공하지 않습니다. 백엔드가 환경 변수에서 제공자 인증 정보를 읽는다면 해당 에이전트의 `env`나 데몬이 상속하는 환경으로 제공하세요. `systemd --user` 서비스는 로그인 셸에서 내보낸 변수를 상속하지 않습니다. 서비스를 통해 제공하려면 드롭인 파일로 설정한 뒤 재시작하세요.

```sh
# ~/.config/systemd/user/chorus-daemon.service.d/provider-env.conf
[Service]
Environment=EXAMPLE_PROVIDER_API_KEY=…
```

```sh
systemctl --user daemon-reload && systemctl --user restart chorus-daemon
```

제공자 인증을 파일에서 읽는 백엔드(예: `~/.claude` / `~/.codex` 아래의 Claude Code와 Codex)는 데몬의 `HOME`만 올바르게 설정되면 되며, 설치된 유닛이 이미 이렇게 설정합니다.

일상적인 운영에는 다음 명령을 사용합니다.

```sh
chorus daemon status
chorus daemon logs
chorus daemon restart
chorus daemon stop
chorus daemon uninstall
```

인증 정보, 작업 디렉터리, 백엔드, 권한 모드를 바꾼 뒤에는 서비스를 다시 설치하거나 재시작하고, **설정 → 에이전트**(Settings → Agents)에서 연결을 확인하세요.

:::note[macOS와 Windows]
macOS에서는 `chorus daemon install`이 Linux에서와 똑같이 실제 launchd 부팅 서비스를 설치합니다. Windows에서는 서비스 템플릿과 수동 설정 단계를 출력하므로, 연결을 테스트할 때의 기준으로 포그라운드 `chorus daemon`을 사용하세요.
:::

### 로그아웃 후에도 Linux 데몬 유지

Chorus 0.21.0부터 `chorus daemon install`은 현재 사용자의 **systemd lingering** 활성화를 시도합니다. 마지막 로그아웃 후에도 사용자 서비스를 유지하고 로그인 없이 부팅 시 시작하기 위한 설정입니다. 권한 확인은 비대화형이며 시간 제한이 있어 비밀번호 대화 상자를 기다리지 않습니다.

권한이 거부되거나 logind를 사용할 수 없어도 서비스 설치는 성공할 수 있지만, 로그아웃 후나 부팅 시 실행을 보장할 수 없다는 경고를 표시합니다. `chorus daemon status`에서 `linger: yes`를 확인하세요. 호스트 정책이 허용한다면 관리자에게 출력된 `sudo loginctl enable-linger <user>` 명령 실행을 요청하세요.

기존 호스트는 `chorus daemon install`을 다시 실행해 복구할 수 있습니다. `chorus agents add`도 서비스 설치 시 또는 기존 서비스 발견 시 lingering을 확인하며, `--daemon-autostart`가 없거나 자동 시작을 거부해도 확인합니다. 두 명령 모두 `--no-linger`로 시도를 건너뛸 수 있지만 기존 설정을 끄지는 않습니다. lingering이 없으면 로그아웃 후 데몬이 멈추고 다음 로그인까지 시작하지 않을 수 있습니다. 다른 사용자 서비스가 필요로 할 수 있어 Chorus 서비스를 제거해도 lingering은 유지됩니다.

## 서비스 없이 실행하기

수명이 짧은 연결이라면 `chorus daemon`을 포그라운드에서 실행합니다. 분리(detached) 모드도 사용할 수 있습니다.

```sh
chorus daemon -d --agent codex --cwd ~/work/project-a --chorus-only
```

같은 `status`, `logs`, `restart`, `stop` 명령으로 관리합니다. 분리 모드를 별도로 작성한 프로세스 관리자와 함께 쓰지 마세요.

## 운영 상태 점검하기

명령줄과 웹의 상태를 모두 확인합니다.

1. `chorus daemon status`를 실행합니다.
2. `chorus daemon logs`로 최근 출력을 확인합니다.
3. **설정 → 에이전트**(Settings → Agents)에서 기대하는 각 작업 디렉터리가 **온라인**(Online)인지 확인합니다.
4. 작은 테스트 세션을 시작해 의도한 디렉터리를 대상으로 하는지 확인합니다.

로그에는 경로, 프롬프트, 명령 출력이 담길 수 있습니다. 공유하기 전에 민감한 값을 제거하세요. 실패한 경우 [에이전트 연결 문제 해결](/ko/guides/troubleshooting/)로 이어 가세요.