Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

High-level SDK cannot authenticate current ACP adapters with dynamic auth methods

Đang mở
  • Có gì không ổn?
#313 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
api, authentication

Hướng nghiên cứu

Start at LiveAcpConnection.create and its private autoAuthenticate helper, then compare initialization capabilities and authenticate support in the low-level acp-http-client. Reproduce the Codex flow with the advertised api-key method and the Claude gateway capability. Done means clients can handle adapter-advertised methods and authentication failures are diagnosable.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

The high-level TypeScript SDK cannot authenticate ACP adapters whose advertised authentication methods differ from the three method IDs hard-coded in autoAuthenticate. It also does not expose a public way to send an arbitrary ACP authenticate request or advertise authentication-related client capabilities.

This currently breaks the official Codex adapter 1.x API-key flow and prevents clients from using the official Claude/Codex custom gateway authentication flow through the high-level SDK.

Versions tested

  • sandbox-agent: 0.4.2
  • acp-http-client: 0.4.2
  • @agentclientprotocol/sdk: 0.16.1
  • @agentclientprotocol/codex-acp: 1.10.0

The same hard-coded authentication logic is still present on main at the time of filing.

Current behavior

LiveAcpConnection.create() initializes the ACP connection and calls a private autoAuthenticate() helper. That helper only considers:

codex-api-key
openai-api-key
anthropic-api-key

Current Codex ACP 1.x advertises:

[
  { "id": "api-key" },
  { "id": "chat-gpt" }
]

As a result, the high-level SDK does not call authenticate, and session creation fails with Authentication required (or an equivalent wrapped ACP error), even when CODEX_API_KEY or OPENAI_API_KEY is available to the adapter process.

The high-level SDK also does not expose its AcpHttpClient, a generic authenticate(request) method, or an authentication callback. Consumers therefore cannot recover by selecting the advertised method themselves.

The authentication call is also best-effort and its error is swallowed, which makes diagnostics difficult.

Claude/custom gateway case

The maintained Claude ACP adapter advertises its gateway auth method only when the client sends the corresponding capability during initialize:

{
  "clientCapabilities": {
    "auth": {
      "_meta": {
        "gateway": true
      }
    }
  }
}

The client must then send an explicit request such as:

{
  "methodId": "gateway",
  "_meta": {
    "gateway": {
      "baseUrl": "https://gateway.example.com",
      "headers": {
        "Authorization": "Bearer <redacted>"
      }
    }
  }
}

The low-level acp-http-client supports both operations. The high-level SDK currently supplies no authentication-related clientCapabilities during initialization and provides no way to issue the explicit authentication request.

Minimal reproduction

  1. Start an official sandbox-agent 0.4.2 server.
  2. Install or use @agentclientprotocol/codex-acp 1.10.0.
  3. Make CODEX_API_KEY available to the adapter process.
  4. Connect with the high-level sandbox-agent TypeScript SDK.
  5. Create a Codex session.

Observed initialize response:

{
  "authMethods": [
    { "id": "api-key", "name": "API Key" },
    { "id": "chat-gpt", "name": "ChatGPT" }
  ]
}

Observed result: session creation fails because no authentication method is selected.

Using the official low-level acp-http-client against the same server succeeds when calling:

await client.authenticate({ methodId: "api-key" });

Expected behavior

The high-level SDK should allow applications to handle the authentication methods advertised by the active adapter, without depending on a fixed list of adapter-specific method IDs.

Possible API shapes include:

  1. Expose a public authenticate(agent, request) or connection-level authenticate(request) method.
  2. Accept clientCapabilities and an authentication selector or callback in the connection options.
  3. Optionally retain automatic authentication for known environment-backed methods, but derive it from advertised method metadata and keep aliases for older adapters.
  4. Surface authentication failures instead of silently swallowing them, or expose them through a diagnostic callback.

Compatibility concern

sandbox-agent install-agent normally resolves adapters from the live ACP registry. Adapter versions therefore evolve independently of the high-level SDK release. A hard-coded method-ID list can become incompatible even when both components are installed through their documented, official paths.

Related

  • #187 requested an explicit SDK or session option to force the Codex auth method.
  • #154 reported Codex credentials being detected while prompt authentication still failed.
Ngôn ngữ chính
TypeScript
Star
1.6k
Fork
134
Merge trung bình
11 giờ 29 phút
Pull request đã merge (30 ngày)
36

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rivet-dev/agents

Tất cả issue của rivet-dev/agents

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.