Skip to content

[Bug]: /compact on ACP registry agents (e.g. Devin) fails at turn start — adapter never sets supportsCompaction #16663

Description

@stilak12

Area: apps/server

Steps to reproduce

  1. Add an ACP registry agent that advertises a compact slash command via available_commands_update (e.g. Devin, acpRegistry_devin).
  2. Open a thread on that provider and send a message or two.
  3. Send /compact (or click Compact context in the context-window meter popover).

Expected behavior

The /compact command is forwarded to the agent and conversation compaction runs (Devin handles /compact natively over ACP and emits compaction_update notifications, which AcpRuntimeModel already maps to a "Compact context" tool-call row).

Actual behavior

The run fails immediately (~500ms) with:

Provider error — "The provider could not start this turn. Retry the turn; if it keeps failing, check the provider setup and server logs."

The provider event log shows initialize and session/load succeed, then the run fails — session/prompt is never sent:

01:00:46.541 initialize      → succeeded
01:00:46.585 session/load    → succeeded
01:00:47.079 run failed      → ProviderAdapterTurnStartError

Impact

Minor bug or occasional failure — compaction is unreachable for every ACP-registry provider, and the UI actively offers a command that cannot succeed.

Root cause

Two capability signals disagree:

  1. Enablement (works): since feat(acp): support local provider commands #16021 ("feat(acp): support local provider commands"), available_commands_update is normalized into the provider snapshot's slashCommands. The web UI enables compact when snapshot.slashCommands.some(c => c.name === "compact") (providerSupportsManualCompaction in ContextWindowMeter.logic.ts). Devin advertises compact, so the UI offers it.

  2. Dispatch (broken): the orchestrator special-cases a message whose trimmed text is exactly /compact and routes it to session.compactThread(...) instead of session.startTurn(...). compactThread is only attached when the adapter flavor sets supportsCompaction: true. The Antigravity and Grok ACP flavors set it; AcpRegistryAdapterV2's flavor does not → the call hits compactThread?.() ?? fail(ProviderAdapterTurnStartError("This provider does not support context compaction.")) and the run dies before session/prompt.

Suggested fix

Set supportsCompaction: true on the acpRegistry flavor. The existing compactThread implementation just calls startTurn with message.text = "/compact", which is correct for any agent that advertises the command — and the UI already gates on advertised commands, so agents that don't advertise compact never get the affordance. (Optionally also gate on the captured slashCommands if you want the runtime side to be defensive too.)

Environment

  • T3 Code: 0.0.46-nightly.20261005.2702 (macOS arm64); still present on main
  • Agent: Devin 3000.11.3 via acpRegistry_devin (devin acp), which advertises 95 commands including compact
  • Verified devin acp accepts /compact via session/prompt directly (returns end_turn, emits compaction_update)

Workaround for users

Attaching any file to the message bypasses the compact dispatch (attachments.length === 0 check), so the prompt goes through session/prompt and the agent parses /compact itself.

Generated with Devin

Activity

  1. juliusmarminge commented on Oct 7, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Confirmed on current main (f8ed2a0). Clear eng bug: UI advertises Compact for ACP-registry agents that expose a compact slash command, but the adapter never opts into compaction, so the orchestrator fails the turn before session/prompt.

    What main does

    1. UI enablement (works). providerSupportsManualCompaction is purely slash-command based:
    // apps/web/src/components/chat/ContextWindowMeter.logic.ts
    return provider?.snapshot.slashCommands.some((command) => command.name === "compact") ?? false;

    #16021 (merged) feeds available_commands_update into the provider snapshot’s slashCommands, so Devin (and any other registry agent that advertises compact) gets the Compact affordance.

    1. Dispatch (broken). Bare /compact (no attachments) is special-cased in RunExecutionService and routed to session.compactThread, not startTurn:
    // apps/server/src/orchestration-v2/RunExecutionService.ts (~1376-1389)
    const compact =
      input.message.attachments.length === 0 &&
      input.message.text.trim().toLowerCase() === "/compact";
    const startTurn = compact
      ? (input.session.compactThread?.(turnInput) ??
        Effect.fail(
          new ProviderAdapterTurnStartError({
            /* ... */
            cause: "This provider does not support context compaction.",
          }),
        ))
      : input.session.startTurn(turnInput);

    That matches the reported ProviderAdapterTurnStartError with no session/prompt.

    1. Adapter gap. AcpAdapterV2 only attaches compactThread when the flavor sets supportsCompaction: true (and that helper just rewrites the message to /compact and calls startTurn):
    // apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.ts (~7393-7400)
    ...(flavor.supportsCompaction === true
      ? {
          compactThread: (turnInput) =>
            startTurn({
              ...turnInput,
              message: { ...turnInput.message, text: "/compact" },
            }),
        }
      : {}),
    • Antigravity / Grok ACP flavors set supportsCompaction: true (AntigravityAdapterV2.ts ~225, GrokAdapterV2.ts ~255).
    • makeAcpRegistryAdapterV2 never sets it — the flavor only wires driver/capabilities/Devin+Mistral exceptions/runtimeCoordinator hooks (AcpRegistryAdapterV2.ts ~190-239). No supportsCompaction symbol in that file on main.

    So any ACP-registry agent that advertises compact gets a button that cannot succeed. The attachment workaround in the report is real: non-empty attachments skips the compact special-case and goes through startTurn → session/prompt.

    Related (not duplicates)

    Ref Notes
    #16021 (merged) Added local ACP slash commands → UI enablement path.
    #5412 (closed) Grok /compact + compaction feedback — different flavor, already sets the flag.
    #11276 (closed) Devin via ACP — landed the provider, not this compaction gate.
    #10164 / #10959 (open) Compaction notification / Claude status UX — unrelated to registry supportsCompaction.

    Fix direction (no open fix PR found)

    Agree with the reporter: set supportsCompaction: true on the acpRegistry flavor. Existing compactThread already forwards /compact via startTurn, which is what Devin expects over ACP. Optionally also gate runtime compact on the captured slashCommands for defense in depth. No open PR from stilak12 (or anyone else) targets this; issue has no comments / linked PRs yet.

    Verdict: valid eng bug — ready to track / fix.

  2. added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 7, 2026
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