[automagik-genie]

Closes #1179.

Summary

`unregisterNativeMember` marked `isActive: false` and left the member in the array. No reader consults inactive entries for history, but two active readers silently pick them up:

1. `resolveNativeMemberName` has an explicit active→inactive fallback (see existing test "prefers active members over inactive"). A stale entry from a prior team membership silently claims messages addressed by name.
2. `findTeamsContainingAgent` — the spawn-resolver tier 5 from feat(tui-spawn-dx): CLI-symmetric agent/team primitives + canonical-UUID invariant #1172 — matches members by `name` regardless of `isActive`. A stale entry routes future spawns into the wrong team.

Observed live: `~/.claude/teams/genie/config.json` had 5 members after a spawn-storm — 2 real plus 3 killed workers all `isActive: false`. Every bare `genie spawn ` hit the stale fallback chain before resolving. Manually purging the file stopped the ghost `teammate-message` announcements.

Fix

`unregisterNativeMember` now removes the member from the array. The per-member inbox at `~/.claude/teams//inboxes/.json` is already cleared by `clearNativeInbox` (called sibling to this in the kill path), so no residual state is worth preserving.

Tests

5 new cases in `claude-native-teams.test.ts`:

• `removes the member entry entirely (not just isActive flip)`
• `is a no-op when the member does not exist`
• `is a no-op when the team does not exist`
• `findTeamsContainingAgent stops matching after unregister (regression)`
• `resolveNativeMemberName stops resolving after unregister (regression)`

The existing `'prefers active members over inactive'` test still passes — `resolveNativeMemberName`'s fallback logic is unchanged; it just never fires because unregistered members are no longer in the array.

Full suite: 2601 pass / 0 fail.

Test plan

• Unit tests cover the 5 cases above
• Full repo test suite passes locally
• CI on `dev` target green
• Manual verification: spawn a worker, kill it, inspect `~/.claude/teams//config.json` — the worker's entry is gone (previously was `isActive: false`).

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2391cab3-57eb-4272-820b-7b933143c6e7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/native-team-kill-removes-member

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request modifies the unregisterNativeMember function to completely remove member entries from the team configuration instead of simply marking them as inactive. This change addresses issues where stale, inactive entries were still being processed by other system components. Accompanying tests have been added to ensure correct behavior and prevent regressions. Feedback suggests that the isActive property and related fallback logic may now be obsolete and should be considered for removal in future maintenance.

[gemini-code-assist]

Since unregisterNativeMember now removes the member from the array instead of marking it as inactive, the isActive property on the NativeTeamMember interface and its associated logic in other functions (such as the fallback in resolveNativeMemberName) appear to be redundant. While out of scope for this immediate fix, consider cleaning these up in a future PR to improve maintainability and avoid confusion about the existence of 'inactive' members.