Question 1

How do I stop Copilot SDK from routing 127.0.0.1 or localhost requests through an HTTP proxy?

Accepted Answer

Set loopback addresses in `NO_PROXY` so local BYOK endpoints bypass the proxy:

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

On Windows (PowerShell):

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

Restart VS Code after setting the variable. A permanent fix was added in the Agent Host PR to automatically append loopback hosts to `NO_PROXY` when it injects `HTTP_PROXY`/`HTTPS_PROXY`; update to a VS Code/Copilot SDK release containing that change.

Question 2

Why does `send_and_wait` resolve early with the wrong result when a spawned sub-agent fails or becomes idle in the Copilot SDK Rust session?

Accepted Answer

This is a bug in `github/copilot-sdk` Rust `v1.0.14` with CLI runtime `1.0.84-5`. The CLI re-emits sub-agent events on the parent session stream with the child's `agent_id`, but `handle_notification` in `rust/src/session.rs` lets every `session.idle`, `session.error`, and `assistant.message` complete the parent's `send_and_wait` waiter without checking `agent_id`.

Fix it by upgrading to a release containing the PR `fix(rust): only root-agent events complete send_and_wait`. As a temporary local patch, restrict waiter completion and last-message updates to root-agent events only:

```rust
// In the send_and_wait waiter arm of handle_notification
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" => {
            // resolve the waiter
        }
        "assistant.message" => {
            // update the waiter's last message
        }
        _ => {}
    }
}
```

Child-tagged events should still be forwarded to `on_event`; they must only be ignored by the `send_and_wait` waiter. Verify with a regression test where an in-flight parent wait receives `session.error` with a child `agent_id` and remains pending, then resolves only after a root `session.idle`.

Question 3

Why does Client::create_session hang when a SessionFsProvider is bound in the Copilot SDK Rust crate?

Accepted Answer

The deadlock occurs because `session.create` is sent before the session event loop is started. During creation, the CLI sends inbound `sessionFs.stat`/`sessionFs.writeFile` requests, but nothing dispatches them yet, so the RPC waits indefinitely. This was fixed in PR `fix(rust): start the session event loop before the session.create RPC` by spawning the event loop before calling `session.create`, matching the existing `session.resume` behavior. Upgrade to a release containing that fix. On `rust/v1.0.14`, the workaround is to patch `start_prepared_create` in `rust/src/session.rs` so `spawn_event_loop` runs before `call_with_inline_callback`.

Question 4

Is it a bug if the Rust router enqueues a request through a sender cloned before the session registration is replaced?

Accepted Answer

No code fix is required. This is not an observable bug. The router task is the sole producer for each per-session channel, and unbounded sends do not block. Therefore, sending through a sender cloned before a concurrent re-registration is equivalent to linearizing that send at lookup time, before the replacement. Holding the router lock across enqueue changes no reachable outcome. Session-ID reuse, unknown-session dropping, and the wire protocol remain unchanged.

copilot-sdk

Overview

README Preview

FAQ (4)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter