Tell the owner when a team member's engine stops reporting to the app, instead of letting it work unseen

Closed
  • Is something wrong?
#326 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

@agentvivekkumar is already working on this.

Since Oct 17, 2026.

  • #455 by @darkcodebyte — open
  • #521 by @agentvivekkumar — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
ai, backend

Research direction

This is design work spanning the hive's hook path. Start with lastHookAt in SafeClearer.noteHook, ensureAgent and its degraded toast in src/main/hive.ts, and HOOK_SHIM there, then src/main/hooks.ts. Done means a fake engine that never calls its hook raises the Needs you card and holds its mail, while a hookless custom command is never flagged. The proposal still needs a design decision on the grace period and on pausing, so check with the maintainer first.

Written by the indexing model from the issue text.

Description

enhancement
Problem / motivation
Problem / motivation

Most of what the app knows about a team member, and several rules it enforces, arrive through the engine's lifecycle hooks: live status, inbox delivery at a safe idle, cost and token caps, the breaker, and the PreToolUse checks. Those checks cover what a settings rule can't: folders made after the member started, Michael's own files, and the hive write guard (hooks.ts, folderCheck and harnessWriteDecision).

When the hooks stop arriving, nothing tells the owner. The team member keeps working in its terminal, and the app stops seeing it:

  • #315. Gemini CLI 0.60 ignores the per-agent system settings file, so a Gemini member gets no hooks at all: no live status, no inbox delivery, no BeforeTool checks. Nothing on screen says so. It was found by reading the settings file by hand.
  • An earlier case is recorded above config:update in src/main/index.ts. After onboarding, the hook server never started, so "no hook ever reaches the app" until the next launch, "which is what hid it."
  • By design, the hook shim lets most tools through when the app can't answer. Only MCP calls are refused, and "everything else never blocks on error" (HOOK_SHIM in src/main/hive.ts). That's right for a blip, because work never stalls. But a bridge that stays down fails open, without a word.

Engines update themselves, so a check that works today can stop on one owner's machine tomorrow, with no change on our side. Today the only signal is the proxy tier's "Agent running degraded" toast, when its bridge doesn't bind at spawn (degraded in hive.ensureAgent). Hook bridges have no equivalent, and nothing checks after spawn.

Proposed solution
Proposed solution

One rule for every engine and bridge kind: a team member the app can't hear from is shown as such, and isn't handed work as if it were supervised.

  1. Expect a check-in. After a spawn, once the member's terminal shows output, its first hook event (any event; Claude, Codex and Gemini all send SessionStart) should arrive within a grace period of about 60 seconds. SafeClearer.noteHook already keeps lastHookAt per agent, so the timestamp exists.
  2. Notice silence while it works. Mark the member out of sight if it never checks in, or if its terminal keeps producing output for several minutes with no hook event. Only members whose preset has a bridge (bridgeOf) count, so a hookless custom command is never flagged.
  3. Tell the owner once, in plain words. Raise one Needs you card, like the one a mailbox gets when its password stops working. For example: "Kelly is working, but the app can't see what she does, so the limits on her folders may not apply. Restart Kelly. If it happens again, her AI engine may have updated." It offers the existing Restart & Continue, and closes itself when a hook arrives.
  4. Hand it no new work while it's out of sight. The router treats it like a member that can't receive mail. Its mail goes to Michael, as canReceiveInbox: false already does, and Michael is told so he doesn't assign it cards.
  5. Owner's choice: where the hook is the only file check (Windows, which has no shell sandbox, and the bridged engines in #48), pause the member instead of only warning. Do this only after the silence is confirmed, never on a blip.

Tests, with no paid calls (they fit the fake-engine run test in #83):

  • a fake engine that writes to its terminal and never calls its hook raises the card, and its mail is held;
  • one that checks in late clears the card;
  • a hookless custom command is never flagged;
  • silence shorter than the grace period does nothing.

Why it fits now:

  • It's engine-neutral, and it protects today's Claude offices, not only future Codex and Gemini ones.
  • It complements #48 and #61. #48 records which rules an engine can enforce. #61 makes sure a hook event comes from the agent it names. This checks the hooks are running on this machine, on this engine version, right now. A conformance run can pass on Gemini 0.59 and still miss #315 on an owner's 0.63.
  • It's small and additive. It reuses lastHookAt, the mailbox's Needs you card, Restart & Continue, and the router's path for members that can't receive mail. Engine settings and the shim don't change.
Screenshot, mockup or recording

No response

Alternatives considered
Alternatives considered
  • A tested version range per engine, with a warning outside it. It would catch #315 only after someone updates the table. And Claude Code updates itself almost weekly, so owners would get constant warnings about versions that work fine. Watching for the check-in catches the actual failure, on any version, with nothing to maintain.
  • Making the shim refuse every tool when the app can't answer. Any hiccup would stop real work, such as an app restart or a slow socket. This proposal keeps the shim lenient for blips and acts only on sustained silence.
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 18h
Merged PRs (30d)
385

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.