Autofix-only change. The OOM-fix commit inserted the progressPayload
import into the wrong position relative to AutoResumeService /
idleNotificationMainProcessSemantics, which failed the
simple-import-sort ESLint rule enforced by CI.
Users with long-running teams (37+ tasks, 10+ agents for an hour) were
hitting constant renderer crashes (issue #36). Two hot paths were
serializing unbounded histories across IPC on every tick:
- Provisioning progress: emitLogsProgress and updateProgress both
joined the full provisioningOutputParts array (~20 event-driven call
sites) plus the full CLI log tail, then fanned that out to the
renderer. After an hour, each tick shipped multi-megabyte payloads
and Zustand OOM'd on the immutable state clone.
- Session detail cache: SessionDetail.messages (the raw parsed JSONL)
was being cached and returned over IPC/HTTP even though the renderer
only reads session/chunks/processes/metrics. This roughly doubled
the per-entry cache footprint on large sessions.
Fixes:
- Add progressPayload helpers that cap the log tail to 200 lines and
assistant output to the last 20 parts; empty/whitespace joins
collapse to undefined so the noop guard is explicit rather than
coincidental.
- Apply the cap inside emitLogsProgress, updateProgress, and the two
inline emission paths (stall warning, retry error). Throttle the
log-progress tick 300ms -> 1000ms so Zustand can keep up.
- Add stripSessionDetailMessages and call it at every SessionDetail
production site that crosses IPC/HTTP (both sessions.ts routes,
both cache stores).
- Raise MAX_CACHE_SESSIONS 5 -> 20 now that the per-entry SessionDetail
footprint is bounded. Previously 5 forced constant re-parsing on
every session switch.
Tests: 15 new unit tests covering the helpers (tail slicing, empty
parts, whitespace-only parts, non-mutation of inputs).
- Added support for live runtime model metadata in team provisioning.
- Implemented functions to extract and manage CLI flag values for team members.
- Updated member specifications to include effective models based on provider defaults.
- Enhanced UI dialogs to check selected providers in parallel, improving responsiveness.
- Added tests for handling model unavailability during team bootstrap and launch processes.
- Introduced CLI_INSTALLER_VERIFY_PROVIDER_MODELS IPC channel for on-demand model verification.
- Implemented handler for verifying provider models in the CliInstallerService.
- Enhanced CLI installation status management with model verification state and availability.
- Updated related components to support model verification feedback in the UI.
* fix(team): resolve stuck "reconciling" state and skip resume when teammates never spawned
Addresses #54.
When a team launch fails to bootstrap teammates, the team gets stuck showing
"Last launch is still reconciling" indefinitely, and retrying with --resume
reconnects the lead but does not re-spawn the dead teammates. The only
workaround was enabling "Clear context (fresh session)", which loses the
lead's prior conversation context.
Two root causes addressed:
1. createPersistedLaunchSnapshot counted members still in 'starting' state
(agentToolAccepted=false) as 'pending' regardless of launchPhase. When
launchPhase was 'finished' with never-spawned members, the aggregate
state stayed as 'partial_pending' forever, rendered as "still reconciling".
Fix: when launchPhase != 'active', promote such members to
'failed_to_start' so the aggregate becomes 'partial_failure'
("Launch failed partway"), which correctly signals a terminal state.
2. TeamProvisioningService._launchTeamInner always used --resume when a
previous leadSessionId existed, even if the previous launch had no
teammates successfully spawned. The CLI's deterministic reconnect path
restores lead context but does not re-spawn dead teammates, so the team
stays broken across relaunches. Fix: before adding --resume, read the
persisted launch state. If every expected teammate is 'starting' (never
spawned) or 'failed_to_start', skip --resume so the CLI performs a full
fresh bootstrap that spawns all teammates.
Verified manually on Linux: a team stuck in "still reconciling" correctly
transitions to "failed partway" after the first fix, and the next Launch
(without "Clear context") fully bootstraps and brings teammates online.
* fix(team): narrow skip resume to never-spawned teammates
---------
Co-authored-by: 777genius <quantjumppro@gmail.com>
seedTeammateOperationalPermissionRules already pre-writes MCP tool
rules to settings.local.json before spawning the CLI. But standard
file tools (Write, Edit, NotebookEdit) were missing.
FACT: Teammates requesting Write get setMode: acceptEdits suggestion
but we can't change subprocess session mode. Pre-seeding these tools
as allow rules prevents the permission prompt entirely.
Belt-and-suspenders approach:
1. Settings file: handles all FUTURE calls (teammate finds rule on retry)
2. control_response via stdin: may unblock CURRENT waiting prompt
(now includes updatedInput: {} which was the previous ZodError fix)
Without #2, approved teammates stay stuck until team restart because
the CLI doesn't hot-reload settings.local.json for pending prompts.
FACT: Write/Edit permission_requests have permission_suggestions with
type "setMode" (not "addRules"): { type: "setMode", mode: "acceptEdits" }
Our code only handled "addRules", so Write/Edit approvals were no-ops.
Translate setMode suggestions to settings rules:
- acceptEdits → add Edit, Write, NotebookEdit to allow list
- bypassPermissions → add all common tools to allow list
- Added mcpToolCatalog to the agent-teams-controller, exporting new types and constants for MCP tool groups and names.
- Updated tools registration to utilize AGENT_TEAMS_MCP_TOOL_GROUPS for streamlined tool management.
- Enhanced tests to validate the new operational permissions and ensure correct tool registration behavior.
When user approves any mcp__agent-teams__* tool, also add all other
agent-teams tools to settings.local.json preemptively. This prevents
teammates from getting stuck on subsequent tool calls (task_get,
task_start, task_complete, etc.) since each generates a separate
permission_request and the teammate blocks until resolved.
FACT: Settings file approach only prevents FUTURE blocks, not current
ones. Pre-adding all tools on first approval covers the common case.
- Added checks to ensure that only newer versions are installed during the update process.
- Updated the notification logic to suppress alerts for non-newer updates.
- Introduced a new method to compare version numbers, improving version management in the UpdaterService.
- Enhanced the release workflow by removing unnecessary file uploads and adding canonical updater metadata publishing for better asset management.
Claude Code CLI Zod schema requires updatedInput to be a record
when behavior is 'allow'. Without it, MCP tool approvals fail with
'Tool permission request failed: ZodError: expected record, received
undefined'.
Add empty updatedInput: {} to all allow responses (autoAllow,
timeout-allow, and manual allow).
Inbox files persist across team runs. Permission_request messages from
a previous run (e.g. when team was launched without auto-approve) were
being reprocessed on the next launch, showing false ToolApprovalSheet
popups even when the new run has bypassPermissions enabled.
Filter by timestamp: skip permission_request messages older than
run.startedAt.
Tool approval settings (autoAllowAll, autoAllowFileEdits, etc.) are
now stored per-team instead of globally. Clicking 'Allow all' in one
team no longer affects other teams.
- localStorage key: 'team:toolApprovalSettings:{teamName}'
- Settings loaded on team select, initialized on create/launch
- skipPermissions=false -> defaults (autoAllowAll:false)
- skipPermissions=true -> autoAllowAll:true for that team
- Main process: Map<teamName, settings> instead of single instance
- IPC: teamName parameter added to updateToolApprovalSettings
- Added logic to remove generated MCP config files when team creation or launch fails due to spawn errors.
- Updated tests to verify that MCP config files are correctly removed in failure scenarios, ensuring no leftover configurations persist.
- Enhanced error handling in the TeamProvisioningService to maintain clean state during provisioning operations.
MCP config files were stored in os.tmpdir() with no cleanup, and
the MCP server ran from the AppImage FUSE mount path which could
be inaccessible to Claude CLI subprocesses on Linux (fixes#31).
Changes:
- Store MCP configs in app.getPath('userData')/mcp-configs/ with
pid+timestamp filenames for safe multi-instance operation
- Copy MCP server to userData/mcp-server/<version>/ via atomic
temp-dir + rename (eliminates FUSE mount dependency)
- Add per-run cleanup in cleanupRun(), startup stale GC (7d TTL),
and shutdown own-pid GC
- Add --mcp-config recovery in respawnAfterAuthFailure()
- Add setAppDataBasePath(null) reset for test isolation
Restored markInboxMessagesRead for permission_request messages in the
early scan. Without this, processed permission_request messages stayed
read=false forever, potentially showing stale unread indicators in UI.
Root cause: handleTeammatePermissionRequest was called from 3 paths
(early inbox scan, Category 4 relay scan, stdout/native) but only
the early scan checked processedPermissionRequestIds, causing
duplicate ToolApprovalRequests and extra permission_responses.
Fix:
- Move processedPermissionRequestIds check INTO handleTeammatePermissionRequest
so ALL callers are protected by the same dedup gate
- Remove duplicate Category 4 scan that re-processed inbox messages
(early scan already covers all messages including read=true)
- Category 4 now only builds a filter Set to exclude permission_request
from relay to lead
Context window fix:
- Derive initial contextWindow from model selection (haiku=200K, else=1M)
- Use limitContext flag from request
- Updated to exact value from modelUsage on result.success
- Formula: input_tokens + cache_creation + cache_read (all three needed)
TokenUsageDisplay:
- New contextWindowSize prop → shows "X% of context" (not "X% of input")
Graph improvements:
- Pending approval: pulsing amber ring on member nodes
- Working spinner: spinning arc when member has active task
- Current task indicator in popover (Loader2 + "working on" + task name)
- GraphNode: added currentTaskId, currentTaskSubject, pendingApproval, activeTool fields
- Adapter: passes pendingApprovalAgents + currentTaskId from store
- Option keys now include question index prefix ("qi:label") to prevent
cross-question collisions when multiple questions share option labels
- Single-select clears only options from the same question, not all
- answersMessage built as per-question JSON map instead of flat join
- Backend parses JSON answers and maps to correct questions
- Fallback label "Option N" for options with undefined label
- Enter key now respects isAskQuestion selection requirement
- Selected option labels sent as message to respondToToolApproval
- control_response includes updatedInput with answers for AskUserQuestion
- useCallback/useEffect deps updated for selectedOptions and hasSelection
relayLeadInboxMessages only processes unread messages after
provisioningComplete, but CLI marks permission_request messages as
read after native delivery -- before our relay runs.
Move permission_request inbox scan BEFORE provisioningComplete check.
Scan ALL messages (including read=true), track processed IDs via
processedPermissionRequestIds Set on ProvisioningRun to prevent
re-emitting. Also look up both alive and provisioning runs so the
scan works during team bootstrap.
- Parse raw user text for permission_request in handleStreamJsonMessage
(covers case where permission_request arrives without <teammate-message> wrapper)
- Add [PERM-TRACE] logger.warn diagnostics to trace the exact flow:
where permission_request is detected, whether it reaches handleTeammatePermissionRequest,
and whether relay or stdout interception triggers
- These logs will help diagnose why ToolApprovalSheet may not appear
relayLeadInboxMessages only runs after provisioningComplete, but
teammate permission_request messages arrive during bootstrap (before
provisioning finishes). Claude Code delivers them natively via stdout
type:"user" messages, bypassing the relay entirely.
Add permission_request interception in handleNativeTeammateUserMessage
which processes stdout user messages at all times, including during
provisioning. This ensures ToolApprovalSheet appears immediately when
teammates need tool permission.
When Claude Code runtime natively delivers permission_request to the
lead via stdout, the message was excluded from interception by the
nativeMatchedMessageIds filter. This caused the ToolApprovalSheet to
not appear for teammate requests.
Remove nativeMatchedMessageIds check from the permission_request
filter so interception works even for natively delivered messages.
When auto-approve is disabled, teammate tool requests arrived as
permission_request JSON via SendMessage and rendered as "Raw JSON"
with no way to approve/deny (#29).
- Intercept permission_request in lead inbox relay, convert to
ToolApprovalRequest and show in existing ToolApprovalSheet
- Respond via teammate inbox (permission_response) + control_response
via stdin as fallback
- Show teammate name in approval header (e.g. "bob — Bash")
- Compact noise label in Messages panel for permission_request/response
- Proper file locking, race condition protection, idempotency checks
- Added a new IPC handler for starting tasks triggered by users, ensuring that the task owner is always notified.
- Introduced `startTaskByUser` method in `TeamDataService` to handle task initiation and notifications.
- Updated relevant components and API interfaces to support the new functionality, including changes in the UI to call `startTaskByUser` instead of the previous `startTask`.
- Documented agent block usage for internal instructions in CLAUDE.md.
This enhancement improves user interaction with task management by providing a clear mechanism for user-initiated task starts.
- Changed references in messages to use the **Agent** tool instead of the Task tool for spawning teammates.
- Added warnings for missing team_name to ensure agents are persistent rather than ephemeral.
- Updated documentation within the code to reflect the new requirements for spawning teammates.
On macOS, the Claude CLI uses a Keychain namespace derived from the
presence of CLAUDE_CONFIG_DIR env var. Setting it to the default
~/.claude creates a different Keychain key than when the var is absent,
causing "not logged in" errors even after successful `claude auth login`.
Only set CLAUDE_CONFIG_DIR when the user has configured a custom path
that differs from the auto-detected default.
Fixes#27
- Upgraded TypeScript target and library to ES2023 for improved language features.
- Enhanced TeamProvisioningService to better handle plain text attachments with UTF-8 validation.
- Improved TaskCommentInput to differentiate between image and non-image file previews, including a new FileIcon for non-image files.
- Refactored attachment handling in useAttachments and useComposerDraft hooks to simplify file processing.
- Added validation for empty files in attachmentUtils to improve user feedback on unsupported uploads.
- Added support for additional attachment types: PDF and plain text.
- Updated the TeamProvisioningService to handle new attachment types with appropriate content blocks.
- Enhanced AttachmentDisplay and AttachmentPreview components to differentiate between image and non-image files.
- Modified DropZoneOverlay and SendMessageDialog to reflect changes in file handling and messaging.
- Improved user experience by allowing file previews for non-image attachments and updating error messages accordingly.
- Refactored attachment validation logic to categorize unsupported files and handle them gracefully.
- Added logic to merge "lead" alias into "team-lead" to prevent phantom member entries in the inbox.
- Updated provisioning instructions to emphasize the importance of using the exact name for the team lead in messages, avoiding abbreviations.
- Modified default role for 'tom' from 'reviewer' to 'researcher' with updated workflow description.
- Improved UI in MemberDraftRow to indicate workflow status with a visual cue when expanded.
Teammates are independent Claude Code processes that read their own inbox
files via fs.watch. Relaying DMs through the lead caused three bugs:
lead responding instead of the teammate, duplicate messages from relay
loops, and teammates not responding to user due to conflicting prompts.
- Disable relayMemberInboxMessages for teammate DMs (teams.ts, index.ts)
- Add SendMessage(to="user") filter in captureSendMessages as safety net
- Generate deterministic messageId for inbox entries lacking one (sha256)
- Wrap notification instructions in agent block, italic task subject
- Style system comments in task view with blue background, hide avatar
- Update CLAUDE.md, research docs, and code comments with architecture
Add explicit constraint in lead prompt forbidding SendMessage with
recipient "*". The broadcast address is not supported by the runtime
and creates a phantom team member named "*" in the UI.
- Revised the TeamProvisioningService to change event handling from 'Task' to 'Agent' for improved accuracy.
- Enhanced the StepProgressBar component to include error indicators and animations for better user feedback during provisioning.
- Updated the TeamProvisioningBanner to track and display the last active step in case of errors.
- Improved CSS styles for step indicators, adding new animations and error states.
- Refined the sidebar task item styling based on light/dark themes for better visual consistency.
- Adjusted the README to reflect changes in installation instructions and feature comparisons.
- Updated the TeamProvisioningService to advance the provisioning state to "assembling" when the first member spawn is detected.
- Improved the clarity of team setup progress tracking by refining the conditions for state transitions.
- Adjusted the README to include a new section on installation and a detailed comparison of features against other multi-agent orchestration tools.
- Updated provisioning states to include 'configuring', 'assembling', and 'finalizing' for better tracking of team setup progress.
- Refactored the provisioning progress block to utilize a new display step system, improving clarity in the UI.
- Adjusted the README to include a comprehensive table of contents and updated comparison metrics for multi-agent orchestration tools.
- Enhanced team management UI to reflect new provisioning states and improve user experience during team setup.
