Question 1

Copilot SDK が 127.0.0.1 または localhost へのリクエストを HTTP プロキシ経由でルーティングしないようにするにはどうすればよいですか？

Accepted Answer

ローカルの BYOK エンドポイントがプロキシをバイパスするように、`NO_PROXY` にループバックアドレスを設定します:

```bash
export NO_PROXY="127.0.0.1,::1,localhost"
export no_proxy="127.0.0.1,::1,localhost"
```

Windows (PowerShell) の場合:

```powershell
$env:NO_PROXY="127.0.0.1,::1,localhost"
$env:no_proxy="127.0.0.1,::1,localhost"
```

変数を設定した後、VS Code を再起動してください。Agent Host PR には、`HTTP_PROXY`/`HTTPS_PROXY` を挿入する際にループバックホストを `NO_PROXY` へ自動的に追加する永続的な修正が加えられました。この変更を含む VS Code/Copilot SDK リリースに更新してください。

Question 2

なぜ Copilot SDK Rust セッションでスポーンされたサブエージェントが失敗したりアイドル状態になったりすると、`send_and_wait` が間違った結果で早期に解決されるのですか?

Accepted Answer

これは、CLI ランタイム `1.0.84-5` を使用する `github/copilot-sdk` Rust `v1.0.14` におけるバグです。CLI はサブエージェントのイベントを子の `agent_id` 付きで親セッションストリームに再送出しますが、`rust/src/session.rs` の `handle_notification` は `agent_id` をチェックせず、すべての `session.idle`、`session.error`、`assistant.message` に対して親の `send_and_wait` ウェイターを完了させてしまいます。

PR `fix(rust): only root-agent events complete send_and_wait` を含むリリースにアップグレードして修正してください。一時的なローカルパッチとして、ウェイターの完了と最終メッセージの更新をルートエージェントのイベントのみに制限します：

```rust
// handle_notification の send_and_wait ウェイターアーム内
let is_root_event = notification
    .agent_id
    .as_ref()
    .is_none_or(|id| id == &root_agent_id);

if is_root_event {
    match notification.method.as_str() {
        "session.idle" | "session.error" => {
            // ウェイターを解決する
        }
        "assistant.message" => {
            // ウェイターの最終メッセージを更新する
        }
        _ => {}
    }
}
```

子タグの付いたイベントは引き続き `on_event` に転送する必要があり、`send_and_wait` ウェイターによってのみ無視されなければなりません。実行中の親の待機が子の `agent_id` を持つ `session.error` を受け取っても保留状態のままとなり、その後ルートの `session.idle` の後にのみ解決されることを確認するリグレッションテストで検証してください。

Question 3

Copilot SDK の Rust クレートで SessionFsProvider がバインドされている場合に、Client::create_session がハングするのはなぜですか？

Accepted Answer

デッドロックが発生するのは、セッションのイベントループが開始される前に `session.create` が送信されるためです。作成中、CLI はインバウンドの `sessionFs.stat`/`sessionFs.writeFile` リクエストを送信しますが、まだそれらをディスパッチするものが存在しないため、RPC は無期限に待機します。この問題は PR `fix(rust): start the session event loop before the session.create RPC` で修正され、`session.create` を呼び出す前にイベントループを起動するように変更され、既存の `session.resume` の動作と一致するようになりました。その修正を含むリリースにアップグレードしてください。`rust/v1.0.14` での回避策は、`rust/src/session.rs` の `start_prepared_create` にパッチを適用し、`spawn_event_loop` が `call_with_inline_callback` より先に実行されるようにすることです。

Question 4

セッション登録が置き換えられる前にcloneされたsenderを通じてRust routerがリクエストをenqueueする場合、それはバグでしょうか？

Accepted Answer

コードの修正は必要ありません。これは観測可能なバグではありません。routerタスクはセッションごとの各チャネルの唯一のプロデューサーであり、unboundedなsendはブロックしません。したがって、並行する再登録より前にクローンされたsenderを介した送信は、そのsendをルックアップ時点、すなわち置換の前に線形化することと同等です。enqueueをまたいでrouterロックを保持しても、到達可能な結果は変わりません。Session-IDの再利用、不明なセッションのドロップ、およびwire protocolは変更されません。

copilot-sdk

概要

README プレビュー

FAQ (4)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter