Releases: hanoong7/Claude_Multi_Agent_Console
Releases · hanoong7/Claude_Multi_Agent_Console
Release list
v0.16.4
feat(v0.16.4): '계속 허용' button — sticky tool approval per session
Permission modal now has two allow paths:
- '✓ 이번 한 번' → one-shot approval
- '✓ 이 도구 계속 허용' → adds the tool name to a per-session sticky set;
future requests for that tool skip the modal
entirely
Server keeps Map<sessionId, Set<toolName>> in memory. /permission
short-circuits in this order:
1. shouldAutoApprove (read-only / safe Bash subset) — always allowed
2. stickyAllow set for the session — user-granted
3. otherwise surface the modal as before
WS permission.response now carries { approved, reason, remember }.
When remember && approved, the tool gets added to the set; the server
console logs '[permission] sticky-allow added: <tool>' for visibility.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.16.3
fix(v0.16.3): server-side auto-approve for safe tools — far fewer modals
Previous diagnosis (v0.15.3) was wrong. The 'too many permission
prompts' issue wasn't 'auto' being an unrecognized mode — it was that
claude's acceptEdits mode auto-approves a much narrower band than
users expect, so most Read/Glob/Grep/git-status/npm-test/etc. calls
were still being routed through our --permission-prompt-tool and
shown as modals.
Fix lives in the server's /permission handler: before broadcasting to
the UI, short-circuit with an allowlist of read-only / well-known safe
tools and Bash command prefixes. Returns approved=true immediately,
no modal:
- tools: Read, Glob, Grep, LS, ListFiles, TodoWrite, TodoRead, Skill
- our own mcp__agent__* (mailbox / task list — internal)
- Bash: ls / pwd / cat / head / tail / wc / file / stat / du / df /
tree, git read-only (status, log, diff, branch, show, …), npm/pnpm/
yarn list+test+--version, python info, which/whereis/type, echo,
date, hostname, whoami, uname, node --version, plain find. Pipes,
redirects, command chaining → not auto-approved.
Everything else (Write, Edit, NotebookEdit, WebFetch, WebSearch,
arbitrary Bash) still routes to the modal. Auto-approvals are logged
to the server console for transparency.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.16.2
feat(v0.16.2): richer queued cards + export conversation as markdown
Queued cards used to just say '<worker-name> (kind) · (예정)' which
gave no real info. Now they show:
- the worker's role description (or first line of role prompt) as a
placeholder for the upcoming task, italic + muted to distinguish
from real spawned-task text
- a row of badges: 대기 + model + effort + permissionMode when those
diverge from defaults
This makes scanning the queue actually useful when several items are
declared in a single <plan>.
Also: ↓ export button in the chat header. Builds a markdown transcript
of the current session (role-labeled headers with timestamps, session
metadata block at the top) and triggers a Blob download named
<title>_<stamp>.md. Includes user / orchestrator / system lines.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.16.0
feat(v0.16.0): light / dark theme toggle
Add a ☀/☾ button in the TopBar that flips between dark (existing) and
light themes. Choice is persisted to localStorage and applied via a
data-theme attribute on <html> at mount.
Approach is var-based rather than a full per-component refactor:
- src/index.css declares semantic CSS vars for bg / text / border under
[data-theme=dark] (default) and [data-theme=light]
- root + body bg+color and scrollbar thumb pull from the vars
- a light-mode override block at the bottom of index.css remaps the
existing hardcoded dark Tailwind classes (bg-[#0b0d10], text-white/...,
border-white/..., bg-white/[0.04], hover:bg-white/...) to light-mode
equivalents so every existing component renders sensibly without
code changes
This keeps the change surface minimal. Subtle accent colors (emerald,
amber, rose) keep their hue in both themes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.15.3
fix(v0.15.3): permission modal shows session + drop fake permission m…
v0.15.2
fix(v0.15.2): in-app prompt dialog + electron.log resets per launch Two small fixes. Session rename from the dashboard didn't work because Electron's Chromium renderer disables window.prompt() entirely. Added an appPrompt() helper alongside appConfirm() in src/confirm.tsx — same custom-modal pattern, with an input field, autofocus + select, Enter to submit, Esc/click-outside to cancel. Dashboard's rename + delete both go through these now. Also: electron.log was opened in append mode, so every relaunch accumulated against the previous session's log. Truncate the file on process start so the log file always represents the current run only. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.15.1
fix(v0.15.1): hide SessionTabs in session view — one session at a time When entering a session from the dashboard, the chat panel was still rendering SessionTabs (all sessions as chips at the top). Remove it so session view is focused on the single active session. Use the '← Multi-Agent Console' button in the TopBar to return to the dashboard and pick another session. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.15.0
feat(v0.15.0): dashboard / orchestrator-view as default landing
App now opens to a dashboard listing every session as a large card,
inspired by Anthropic's Agent View. Cards show title, status pill
(live / 승인 대기 / idle), relative last-activity time, currently
running worker chips (worker-colored pulse dot), and a 3-line preview
of the most recent message. Hover reveals 이름/삭제. Click anywhere on
a card to enter that session's full 3-panel view.
- src/Dashboard.tsx (new): grid component with SessionCard, empty
state, and '+ 새 세션' button
- src/App.tsx: persisted view state ('dashboard' | 'session') in
localStorage; conditional render of Dashboard vs the existing
3-panel layout; helpers enterSession / newSession that set
activeSessionId and flip view
- TopBar logo becomes '← Multi-Agent Console' when in session view,
clicking returns to the dashboard
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.14.0
feat(v0.14.0): adversarial debate mode toggle (#4)
Optional opt-in mode: when enabled, evaluation/judgment steps
(REVIEW / INVESTIGATE / large-decision PLAN) auto-spawn two workers
with opposing stances, exchange one round of rebuttals via the
mailbox, then synthesize a consolidated answer that acknowledges
both views.
- types.ts: OrchestratorConfig.adversarialMode: boolean
- server.mjs: DEFAULT_ORCH default false; orchestrator.update accepts
the field; new ADVERSARIAL_BLOCK appended to the orchestrator
system prompt when on (after APPROVAL_BLOCK). Builds on the
existing mailbox + shared task list (v0.13.0).
- store.ts: initial state matches.
- App.tsx TopBar: new checkbox alongside the plan-approval one,
amber accent.
IMPLEMENT (coder) / DESIGN (designer) steps are explicitly excluded
from debate — those are output-generation, not judgment.
Max one rebuttal round to keep latency reasonable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v0.13.0
feat(v0.13.0): distributed workers — mailbox + shared task list (#1+2)
Workers (and the orchestrator) can now coordinate peer-to-peer through
six new MCP tools instead of every information path going through the
orchestrator.
New file: server/agent-mcp.mjs — stdio MCP server exposing:
- send_message(from, to, content): peer-to-peer DM, lands in target's inbox
- read_inbox(from): drain your own incoming messages
- create_task(from, title, description?, assignee?): add to shared task board
- list_tasks(from, status?): see pending / in_progress / completed across team
- claim_task(from, id): self-assign a pending task
- complete_task(from, id, summary?): mark done with outcome
Every call carries 'from' = the caller's worker key, since all subagents
spawned from one claude session share the same MCP server instance and
env vars can't differentiate per-worker. The orchestrator's
buildAgentsFlag now prepends a worker-key + coord-tool instruction to
each worker's role prompt so they know their key and how to use the
tools.
Server (server.mjs):
- inboxes: Map<sessionId, Map<workerKey, Message[]>>
- taskLists: Map<sessionId, Task[]>
- HTTP endpoints under /agent/* that agent-mcp.mjs proxies to
- emitAgentEvent broadcasts coordination activity (✉ A→B, ＋ task, ▸ claim,
✓ complete) as system chat messages so the user sees the workflow
- MCP config in claude spawn now includes BOTH permission + agent servers
- Orchestrator system prompt teaches when to use the task board vs the
Agent tool, and tells workers to call read_inbox at the start of work
Build:
- copy + asarUnpack agent-mcp.mjs alongside permission-mcp.mjs
UI work intentionally minimal for MVP — coordination activity surfaces in
the chat log via system messages. Dedicated task / inbox panels can come
in a follow-up.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>