Keep what each engine can do in one table instead of Claude checks spread through the code

Open
  • Is something wrong?
#531 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@Sanketmis208 is already working on this.

Since Oct 20, 2026.

  • #577 by @Sanketmis208 — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
ai-infra-agents, testing, tooling

Research direction

Start by reading the engine presets and the existing capability checks named in the issue, especially isClaudeProvider and the fields hiveAware, canReceiveInbox, resumeFlag, and supportsModel. Then locate BUILD_ENGINES and the existing tests around engine configuration. Done means a typed capability table covers each engine, engineGaps(engine, os, needs) reports missing capabilities, and a test fails when an engine lacks an entry.

Written by the indexing model from the issue text.

Description

enhancement
Problem / motivation

I was reading how workers get spawned and noticed that what Claude can do and other engines can't is decided inline, in many places.

  • isClaudeProvider(...) has 17 call sites in 8 files (hive.ts, index.ts, AddAgentModal, EditAgentModal, OnboardingWizard, ResearchPrivacySettings, useHive, store/config.ts).
  • index.ts and hive.ts each put the result in a local claudeProvider and branch on it again and again. In the spawn code in index.ts it gates connectors, the per-agent scratch folder, the Claude-only flags and resume, the permission mode, the mailbox MCP, recording the Claude Code version, and Research refusing a non-Claude engine.
  • Four more places compare provider === 'claude' directly (CommandCenterPanel, store/config.ts, providerAutomation.ts, teamAdvice.ts).
  • A few things are proper preset fields (hiveAware, canReceiveInbox, resumeFlag, supportsModel), and some gaps only exist as open issues (#298, #414, #357, #109).

So if someone adds Codex to BUILD_ENGINES (still ['claude']), they have to find every one of these by hand and work out what that engine is missing. #48 and #139 cover this for folder privacy. The same problem exists for everything else.

Closest are #48, #139 (closed as a dupe of #48), #443 and #83. They cover enforcement and testing. This is the general table.

Proposed solution

A small table, one entry per engine, saying what it supports: system prompt on resume, hooks, tool guards, file sandbox, context gauge, resume, which OSes, which versions we've tested. Filled in from the preset fields we already have, and unknown where nobody has checked.

Plus a pure engineGaps(engine, os, needs) that returns what an engine is missing, and a test that fails if an engine is added without an entry.

I'd start with just the types, the table, the function and the test. No behavior change and no call sites touched. Replacing the checks can come later, one PR at a time. This could also be where #48's enforces record lives.

Screenshot, mockup or recording

No response

Alternatives considered

Leave it as is, or do it as part of #48. I'd rather not tie this small step to the bigger compiler change.

Area

The hive (memory, routing, GOD agent)

Pre-flight
  • I attached a screenshot, mockup or recording above.
  • I searched existing issues and discussions, and this isn't a duplicate.
Dominant language
TypeScript
Stars
273
Forks
211
Avg merge
2d 9h
Merged PRs (30d)
367

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentvivekkumar/dontbemichael

All issues in agentvivekkumar/dontbemichael

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.