Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#313 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
1.6k
Forks
131
Merge medio
7 h 40 min
PR fusionados (30 d)
29

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rivet-dev/agents

Todos los issues de rivet-dev/agents

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.