hoangsonww/Claude-Code-Agent-Monitor

Hi @hoangsonww, thanks for building and maintaining this. The dashboard has become part of my daily setup, and the Kanban board is the view I keep open most, because it shows every agent and where it is at a glance. One small thing: agent card titles are nearly always cut off (e.g. Cursor · Inte…, Claude Co…). Columns are 288px wide (w-72), so after the icon and the status badge the title gets about 80px, and the Cursor · / Claude Code · prefix takes most of it. Some of what's on the card is repeated: The column already shows the status, so the badge repeats it on the Kanban board. Cursor's subtitle already says "Cursor", so the prefix appears twice. On Claude Code cards, the session name shows in the title and again in the footer, next to the session ID. Proposal Using the same colors and components as today: Show only the session's own title on the card, clamped to 2 lines instead of 1. Move the tool name to the start of the subtitle for all tools (Claude Code · repo ·

Summary Audit all pluralized dashboard translations for plural categories selected by the supported locales. Add consistent _many coverage where i18next selects many, rather than fixing only the three count labels migrated in PR #349. Include Spanish (es) and the French (fr), Portuguese (pt, pt-BR), and Italian (it) locales introduced in PR #348. Check all other configured locales for the same issue. Rationale Intl.PluralRules("es").select(1000000) returns many. Without a matching _many translation, i18next can fall back to English instead of using the locale's _other text. This also affects plural keys that predate PR #349, such as kanban:session.agentSummary and sessions:taskProgress.doneCount. The client i18n parity test requires matching translation key sets across locales, so coverage changes must account for every locale. Affected areas client/src/i18n/locales/: audit every plural key in each namespace and supported locale; add required _many entries while preserving translation

Reporting this as an issue rather than a PR — I'd rather not sign the CLA, so please treat the patch sketch below as public-domain guidance and write it however you like. Summary getUpdatesStatus(cwd) is contracted to inspect the repository named by cwd. It doesn't. execGit passes the ambient environment through, and git's location variables (GIT_DIR, GIT_WORK_TREE, GIT_INDEX_FILE) override cwd. Git exports those — plus GIT_AUTHOR_* — to hooks. .husky/pre-commit runs npm run test:server. So every commit attempt in this repo runs the test suite with those variables set. Why it's destructive server/__tests__/update-check.test.js builds throw-away repos and commits into them. With GIT_DIR inherited, git add . uses the temp directory as its working directory but writes the real repository's index — which then holds only the fixture's README.md. The commit records every other tracked file as deleted. We hit this on a downstream fork. Four commits messaged init appeared on a working

What problem does this solve? GET /api/agents and GET /api/sessions compute each row's "last activity" with a correlated subquery, MAX(e.created_at) FROM events e WHERE e.agent_id = a.id (and the same on session_id). Existing ID-leading indexes, (agent_id, event_type), (session_id) and (session_id, event_type), narrow the matching rows, but none orders them by created_at, so SQLite still examines every entry in each matching range to compute the maximum. On a copied database with about 355k events and 11,392 agents, the unfiltered 10,000-row agent-list query averaged 787 ms across two runs; a separate 50-row query isolating session last activity averaged 523 ms. These are diagnostic SQL timings, not end-to-end timings of the Dashboard's filtered requests. While the Dashboard is open, selected WebSocket messages schedule a reload through a 2 s trailing throttle, with a 10 s poll as a backstop, so the cost repeats while sessions are active. Proposed solution Add two indexes in the startu

What problem does this solve? On one installation, having one long-running Claude Code session open made every task-progress-enabled session-list request slow, and the dashboard process stayed busy while the browser was idle. That session has a 329 MB transcript, 284 subagent transcripts (273 MB) and 4,386 persisted lifecycle events. While the Dashboard page was open, three plain GET /api/sessions calls from the shell took 22.5 s, 13.7 s and 18.5 s, because they queued behind the browser's include_task_progress=1 reloads, each of which blocked the event loop for several seconds. The server sat at ~73% CPU with RSS at 2.5 GB. The Dashboard and Sessions pages schedule reloads for selected WebSocket messages through a 2 s trailing throttle, so sustained hook activity repeats this work continuously. A CPU profile (12 s sample) put ~80% of the time in task-progress derivation (server/lib/task-progress.js parseFileLines / JSON.parse) and the per-session task-event query. Three separate cause