Skip to content

fix(agent): mark claude-compat harnesses (grok/devin/continue) signal-capable#2405

Open
abhay-codes07 wants to merge 1 commit into
AgentWrapper:mainfrom
abhay-codes07:fix/claude-compat-harness-signal-capable
Open

fix(agent): mark claude-compat harnesses (grok/devin/continue) signal-capable#2405
abhay-codes07 wants to merge 1 commit into
AgentWrapper:mainfrom
abhay-codes07:fix/claude-compat-harness-signal-capable

Conversation

@abhay-codes07

Copy link
Copy Markdown

Closes #2402.

What

SupportsHarness backs the SignalCapable input to status derivation: a signal-capable harness that goes silent past the 90s noSignalGrace is shown no_signal (broken hook pipeline), while a hook-less harness stays idle. It decided capability by looking the harness name up in Derivers.

grok, devin, and continue are Claude-compat harnesses — their GetAgentHooks delegates to the claude-code plugin, installing byte-identical ao hooks claude-code <evt> callbacks, so they have a fully working activity pipeline (routed through the registered claude-code deriver at runtime). But their harness names aren't Derivers keys, so SupportsHarness returned false for them: a grok session and a claude-code session install the same bytes, yet a broken-hook grok session was shown a confident idle forever instead of no_signal.

Change

Track the three delegating harnesses in a small claudeCompatHarnesses set and have SupportsHarness consult it, without polluting the runtime dispatch Derivers map (nothing emits ao hooks grok). Kept as a dedicated set so Derivers stays the single source of truth for runtime dispatch.

Tests

  • Added TestSupportsHarnessClaudeCompatDelegates asserting grok/devin/continue are signal-capable. Fails before the change (all false), passes after.
  • Existing TestSupportsHarness (hook-less harnesses stay false) and TestDeriverTokensAreKnownHarnesses still pass.
  • go test ./internal/adapters/agent/activitydispatch/... green; go vet and gofmt clean.

cc @harshitsinghbhandari — these three delegate to claude-code's hooks, so they seemed like they should match claude-code's no_signal behavior; open to a different shape if you prefer.

…-capable

SupportsHarness backs the SignalCapable input to status derivation: a
signal-capable harness whose hooks go silent past the no_signal grace is shown
"no_signal" (broken pipeline), while a hook-less harness stays "idle". It decided
capability by looking the harness name up in Derivers.

grok, devin, and continue are Claude-compat harnesses: their GetAgentHooks
delegates to the claude-code plugin, installing byte-identical
`ao hooks claude-code <evt>` callbacks, so they have a fully working activity
pipeline (routed through the registered claude-code deriver at runtime). But their
harness names aren't Derivers keys, so SupportsHarness returned false for them — a
grok session and a claude-code session install the same bytes, yet a broken-hook
grok session was shown a confident "idle" forever instead of "no_signal".

Track the three delegating harnesses in a small claudeCompatHarnesses set and have
SupportsHarness consult it, without polluting the runtime dispatch map (nothing
emits `ao hooks grok`). Adds a regression test.
Copilot AI review requested due to automatic review settings July 4, 2026 06:28

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(agent): grok/devin/continue not marked signal-capable despite installing claude-code hooks

2 participants