Skip to content

[Bug]: ACP agents built on the Kotlin ACP SDK (e.g. Junie) never become ready: request ids start at 2^32 #15263

Open
#15374
Open
[Bug]: ACP agents built on the Kotlin ACP SDK (e.g. Junie) never become ready: request ids start at 2^32#15263
#15374
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@ch-iwi
ch-iwi
opened on Oct 3, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Open Settings → Providers → Add provider, search the ACP Registry for Junie (junie, 3419.24.0) and add it.
  2. Wait for the provider status check, or refresh providers.
  3. Junie never reaches a ready state; every status check fails after 60 seconds.

Minimal repro without T3 Code (shows the root cause): start the registry binary with junie --acp=true and write one JSON-RPC line to its stdin:

{"jsonrpc":"2.0","id":4294967296,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{"fs":{"readTextFile":false,"writeTextFile":false},"terminal":false}}}

No response is ever written. The same request with "id":1 (or "id":1073741824) is answered in about 1 s, and session/new succeeds right after.

Expected behavior

Junie initializes, the status probe creates a test session, and the provider becomes ready for chat.

Actual behavior

The probe always times out. packages/effect-acp starts Effect RPC request ids at 2 ** 32 (client.ts and agent.ts, let nextRpcRequestId = 2 ** 32) so they don't collide with extension request ids, which count up from 1. Junie is built on the official Kotlin ACP SDK, whose RequestId.IntId holds a Kotlin Int. Its RequestIdSerializer decodes numeric ids with element.content.toInt(), which throws for 4294967296. The frame is treated as malformed and nothing is sent back, so T3 waits until its 60 s probe timeout.

The ACP schema allows these ids (RequestId is integer/int64 in both v1 and v2, unchanged since v0.10.0), so this is an interop bug with a widely used SDK rather than a T3 spec violation. Any ACP Registry agent built on the Kotlin SDK should be affected, not only Junie.

Probe results against Junie 3419.24 (initialize → session/new):

First request id Result
1 initialize 0.9 s, session 1.5 s
1073741824 (2^30) initialize 1.0 s, session 1.7 s
4294967296 (2^32) no response after 20 s

Impact

Blocks work completely

Version or commit

main @ 1945ce8

Environment

macOS 27.0 (Apple Silicon), Node 24.21.0, Junie ACP 3419.24 (agentInfo version 26.9.22) via the ACP Registry

Logs or stack traces

# ~/.t3/userdata/logs/server.trace.ndjson, span AcpRegistryProbe.probeConfiguration (repeats on every refresh)
AcpRegistryOperationError: The ACP agent did not resolve and create a test session within 60 seconds. Package installation or agent startup may be slow; this check retries on the next provider refresh.
    at AcpRegistryProbe.probeConfiguration
    at AcpRegistryDriver.checkProviderStatus
    at restartSnapshotEnrichment
    at applySnapshot
    at refreshSnapshot


`~/.t3/userdata/logs/provider/` stays empty because no thread session ever starts.

Screenshots, recordings, or supporting files

No response

Workaround

None in the app. A fix is to start RPC request ids inside the signed 32-bit range (for example 2 ** 30), which still leaves about 1e9 extension ids before the ranges could meet. Responses are routed by the pending extension-request map first, so the lower offset does not introduce misrouting.

Separately, the root limitation is in the Kotlin SDK (Int instead of Long for int64 ids, and malformed frames get no error reply); that is worth reporting to agentclientprotocol/kotlin-sdk.

Activity

  1. ch-iwi
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 3, 2026

  2. juliusmarminge commented on Oct 3, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 3, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    Thanks @ch-iwi for the very thorough report and the minimal repro. I confirmed this on current main, and the code matches what you describe.

    What's happening

    • AcpClient and AcpAgent both start Effect RPC request ids at 2 ** 32 (packages/effect-acp/src/client.ts, packages/effect-acp/src/agent.ts). Extension requests still count up from 1 (packages/effect-acp/src/protocol.ts).
    • Incoming replies are matched against the pending extension-request map first. Any other numeric id goes to the Effect RPC client.
    • The Kotlin ACP SDK stores RequestId.IntId as a Kotlin Int and decodes numeric ids with element.content.toInt(), so 4294967296 fails and the frame is treated as malformed.
    • Current SDK source answers a malformed request with a JSON-RPC error whose id is null. T3 only forwards numeric ids to the RPC client, so that reply is dropped. Older SDK builds may just stay silent. Either way initialize stays pending until the 60 second AcpRegistryProbe.probeConfiguration timeout.
    • ACP's RequestId is int64, so T3 is within spec. In practice the break is the signed 32-bit limit: 2 ** 31 would already fail toInt().

    Likely fix area

    nextRpcRequestId in packages/effect-acp (client and agent). Some options:

    • Start the RPC counter inside the signed 32-bit range (for example 2 ** 30, as you suggested), in both the client and the agent. That still leaves roughly a billion per-connection ids before the extension counter could meet it.
    • String ids are allowed by the schema, but isEffectRpcRequestId only forwards numbers today, so they'd need extra handling to avoid being dropped the same way.
    • Separately, reporting upstream to agentclientprotocol/kotlin-sdk (decode int64 ids as Long, and echo the original id on malformed requests when possible) would help other clients too.

    A maintainer will decide on the fix direction.

  3. juliusmarminge
    added
    via-triageFiled through npx t3 triage
    and removed
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 3, 2026

  4. mymmrac commented on Oct 8, 2026

    @mymmrac
    mymmrac
    on Oct 8, 2026

    Hi, any updates on this issue? This blocks any usage of Junie AI and fix proposed in #15374 seems to be simple and effective, it's better to have Kotlin SDK fixed, but based on repo activity I am not sure how long it would take for them to fix it. Other projects seems to support Junie without issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions