← reports

#4378 · ACP Grok compaction rejected by capability gate

BugMedium priorityLow effortproviders · provider-acpopen on GitHub2026-09-25 · base 9c9bae7f36a237c7e1b96de3d4c2186d13967686

Verdict: REPRODUCED · Root-cause confidence: high for bb's rejection. A long Grok session was not run, so effective context reduction remains unverified.

1. TL;DR

bb rejects manual context compaction for an idle Grok ACP thread with HTTP 409. A route-level regression test reaches that response on trusted main in two clean checkouts. The built-in Grok provider does not opt into manual compaction, so the server rejects the request before submitting a turn. The existing ACP bridge has a path for sending the structured compaction request as a /compact prompt. This investigation proves the bb gate defect; it does not prove Grok's behavior after the request reaches a long live session.

2. Claims vs findings

3. Environment

• Trusted bb base: 9c9bae7f36a237c7e1b96de3d4c2186d13967686; Linux x86_64; Node v26.8.1; pnpm 9.15.0.
• Frozen dependency install and full Turbo build succeeded in both checkouts. The test used the repository's in-memory server harness. No running app, network port, real data directory, or Grok provider process was used.

4. Minimal reproduction

1. At the recorded commit in a clean checkout, install and build the repository:

   pnpm install --frozen-lockfile --prefer-offline
   pnpm exec turbo run build

2. In apps/server/test/public/public-thread-compaction.test.ts, replace the existing ACP compaction test with the complete case shown below, then run its Grok case.

   pnpm exec turbo run test --filter=@bb/server -- test/public/public-thread-compaction.test.ts -t acp-grok

This case uses the real first-party provider declaration, a real in-memory database, and the public HTTP route. It expects a successful response followed by a structured compaction turn submission:

  it.each(["acp-omp", "acp-grok"])(
    "routes %s compaction onto the bridge's /compact turn",
    async (providerId) => {
    await withTestHarness(async (harness) => {
      const { host, session, thread } = seedCompactableThread(harness, {
        providerId,
        providerThreadId: "provider-thread-acp",
      });
      const responder = registerSuccessfulTurnResponder(harness, {
        hostId: host.id,
        sessionId: session.id,
      });

      const response = await harness.app.request(
        `/api/v1/threads/${thread.id}/compact`,
        { method: "POST" },
      );
      expect(
        response.status,
        JSON.stringify(await readJson(response.clone())),
      ).toBe(200);
      const turnSubmitRequests = responder.requests.filter(
        ({ command }) => command.type === "turn.submit",
      );
      expect(turnSubmitRequests).toHaveLength(1);
      expect(turnSubmitRequests[0]?.command).toMatchObject({
        type: "turn.submit",
        threadId: thread.id,
        input: createStandaloneBuiltinCompactCommandInput(),
        resumeContext: {
          providerId,
          providerThreadId: "provider-thread-acp",
        },
      });
    });
    },
  );

Expected: HTTP 200, then one structured turn.submit with the built-in compaction input. Actual on main:

FAIL public thread compaction > routes acp-grok compaction onto the bridge's /compact turn
AssertionError: {"code":"invalid_request","message":"Provider \"acp-grok\" does not support manual context compaction"}: expected 409 to be 200
Test Files  1 failed (1)

5. Root cause

The Grok built-in definition has no manual compaction capability. ACP defaults it to false, and declaration assembly only overrides it when the agent opts in. The server gate then returns HTTP 409. The ACP bridge compaction path is unreachable from this request. This is a missing built-in provider capability declaration.

6. Proposed fix

Opt the Grok built-in provider into manual compaction in the existing ACP provider declaration and keep the route-level regression case. Verify that the request becomes a structured compaction turn. Test a long live Grok session separately if exact provider completion and failure semantics need confirmation.

7. Related issues

#2290 records an earlier missing compaction capability for a different ACP provider; it is closed. No linked open pull request was found for #4378.

8. Verification

After the first route-level failure, a second detached checkout at the exact recorded base commit received the same regression patch. Its frozen install and full build succeeded. The first test attempt ran out of temporary inodes before test collection; a retry with a separate temporary directory completed and failed at the same HTTP 409 assertion. No report finding changed.

9. Appendix

Commands used: git fetch origin main, git rev-parse origin/main, pnpm install --frozen-lockfile --prefer-offline, pnpm exec turbo run build, and the focused test command above. The second checkout used the same test through Vitest directly after Turbo built its dependencies because the shared temporary filesystem was out of inodes. Issue content was treated as untrusted claims; no code, command, or external link from it was executed.