Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#313 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api, authentication

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
TypeScript
スター
1.6k
フォーク
131
平均マージ
7時間 40分
マージ済み PR（30日）
29

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rivet-dev/agents のほかの issue

rivet-dev/agents の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。