zopkit-bug-resolution-mcp 1.8.0 → 1.9.1

package/bin/zopkit-statusline.js

@@ -35,7 +35,7 @@
 import { readFileSync, writeFileSync, mkdirSync } from 'node:fs';
 import { join } from 'node:path';
 import { homedir, tmpdir } from 'node:os';
-import { loadConfig, post, readStdinJson } from '../lib/zopkit-config.js';
+import { loadConfig, post, readStdinJson, readClaudeAccount, reporterVersion } from '../lib/zopkit-config.js';
 
 // Per-session throttle. The status line fires on every assistant message; a
 // 40-turn session would otherwise be 40 POSTs. 15s keeps the panel's 10s
@@ -94,6 +94,9 @@ function buildHeartbeat(p, cfg, fresh) {
     sessionName: cfg.shareSessionName ? (p.session_name ?? null) : null,
     model: p.model?.id ?? null,
     version: p.version ?? null,
+    // This reporter's version, so the server can tell "old client" apart
+    // from "nothing to report" — they produce identical rows otherwise.
+    reporterVersion: reporterVersion(),
 
     contextTokens: p.context_window?.total_input_tokens ?? null,
     contextLimit: p.context_window?.context_window_size ?? null,
@@ -112,6 +115,10 @@ function buildHeartbeat(p, cfg, fresh) {
 
     rateLimits: p.rate_limits ?? null,
 
+    // Which Anthropic account this session is signed in to. Read from
+    // ~/.claude.json rather than the payload, which does not carry it.
+    account: readClaudeAccount(),
+
     // Whether a NEW API response landed since the last heartbeat for this
     // session, detected by the context token count moving. Only a fresh
     // reading may advance the account-level percentages: an idle session's

package/index.js

@@ -91,7 +91,7 @@ if (!API_KEY) {
     'Generate one from the company-admin panel (Bug Reports → API Keys) and set it when registering this server.');
 }
 
-const server = new McpServer({ name: 'zopkit-bug-resolution', version: '1.8.0' });
+const server = new McpServer({ name: 'zopkit-bug-resolution', version: '1.9.1' });
 
 const BUG_SEVERITIES = ['low', 'medium', 'high', 'critical'];
 // Keep in sync with BUG_STATUSES in backend/src/db/schema/platform/bug-reports.ts.
@@ -139,18 +139,28 @@ const SUBAGENT_TOOL_NAMES = new Set(['Agent', 'Task']);
 // weeklySessionsWithWebSearch; missing this half undercounted it before.
 const WEB_TOOL_NAMES = new Set(['WebSearch', 'WebFetch']);
 
-// Context-window ceiling per model family — used only to turn
-// currentContextTokens into a percentage the panel can render as a bar.
-// Heuristic, not queried from Anthropic (there's no local API for "is this
-// account's extended-context beta on"): Sonnet ships with a 1M-token beta
-// context window in Claude Code; Opus/Haiku are the standard 200k. Falls
-// back to 200k for anything unrecognized — an undercount of the true limit
-// is the safe failure direction (a 1M-context Opus session would just show
-// as "over 100%", visibly wrong and prompting a fix, not silently hidden).
+// Context-window ceiling per model, used only to turn currentContextTokens
+// into a percentage. A GUESS, and unavoidably so: the transcript records no
+// window size (only context_management), so unlike the status-line path —
+// which is handed context_window.context_window_size by Claude Code itself
+// — this has to infer it.
+//
+// The previous rule was "sonnet => 1M, everything else => 200k", which put
+// every Opus 5 session at a fifth of its real ceiling: a session the status
+// line measured at 626k/1.0M (63%) showed here as 626k/200k, pinned red at
+// 100%. The 5-series ships the 1M window; 4.x is 200k.
+//
+// Note the version is parsed positionally, not by substring: the family
+// version is the segment right after the name, so claude-haiku-4-5-20251001
+// is a 4-series despite containing "-5-".
 function contextLimitForModel(model) {
   if (!model) return 200_000;
-  if (model.includes('sonnet')) return 1_000_000;
-  return 200_000;
+  const [, version] = model.replace(/^claude-/, '').split('-');
+  const major = Number.parseInt(version, 10);
+  // Unrecognised => 200k. Undercounting the ceiling shows a session as
+  // fuller than it is, which is visibly wrong and gets reported; guessing
+  // high would quietly hide a session that is genuinely about to run out.
+  return Number.isFinite(major) && major >= 5 ? 1_000_000 : 200_000;
 }
 
 /**

package/lib/zopkit-config.js

@@ -16,11 +16,76 @@
 // Create it with:  npx zopkit-bug-resolution-mcp --init-usage-reporting
 
 import { readFileSync } from 'node:fs';
-import { join } from 'node:path';
+import { join, dirname } from 'node:path';
 import { homedir } from 'node:os';
+import { fileURLToPath } from 'node:url';
 
 export const CONFIG_PATH = join(homedir(), '.claude', '.zopkit-usage.json');
 
+/**
+ * This reporter's own version, sent with every heartbeat.
+ *
+ * The server cannot otherwise tell an OLD reporter apart from a machine
+ * with nothing to report: a pre-1.9.0 client sends perfect session rows
+ * and silently omits the account, which looks identical to a machine that
+ * has no signed-in Claude account. Both show up as "not reporting" and
+ * need completely different fixes.
+ *
+ * Read from package.json rather than hardcoded, so it cannot drift from
+ * the published version the way a duplicated constant would.
+ */
+let versionCache;
+export function reporterVersion() {
+  if (versionCache !== undefined) return versionCache;
+  try {
+    const here = dirname(fileURLToPath(import.meta.url));
+    versionCache = JSON.parse(readFileSync(join(here, '..', 'package.json'), 'utf8')).version ?? null;
+  } catch {
+    versionCache = null;
+  }
+  return versionCache;
+}
+
+/**
+ * Which Anthropic account this machine is signed in to.
+ *
+ * Read from ~/.claude.json's oauthAccount block — the same file Claude
+ * Code keeps its own settings in. Nothing here is a credential: the uuid
+ * is an identifier, and the email/org are what the account calls itself.
+ *
+ * It matters because RATE LIMITS ARE PER ACCOUNT. The wrapper staff member
+ * reading the panel and the Claude account being billed need not be the
+ * same identity (on the machine this was written, they are not), and if
+ * two developers share one account then "this developer is at 70%" is the
+ * wrong sentence — the account is, and the token split says who drove it.
+ *
+ * Cached for the process: a status line runs on every assistant message
+ * and this file is ~MBs, so re-reading it per render would be the most
+ * expensive thing the reporter does.
+ */
+let accountCache;
+export function readClaudeAccount() {
+  if (accountCache !== undefined) return accountCache;
+  try {
+    const raw = JSON.parse(readFileSync(join(homedir(), '.claude.json'), 'utf8'));
+    const a = raw?.oauthAccount;
+    accountCache = a?.accountUuid
+      ? {
+          uuid: a.accountUuid,
+          email: a.emailAddress ?? null,
+          orgName: a.organizationName ?? null,
+          // The rate-limit TIER, not the seat: it is what explains why two
+          // accounts have different ceilings, so a high percentage on a
+          // small plan is not read as the same signal as one on a 20x.
+          plan: a.organizationRateLimitTier ?? a.organizationType ?? null,
+        }
+      : null;
+  } catch {
+    accountCache = null; // never signed in, or an unreadable file
+  }
+  return accountCache;
+}
+
 let cached;
 
 export function loadConfig() {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zopkit-bug-resolution-mcp",
-  "version": "1.8.0",
+  "version": "1.9.1",
   "type": "module",
   "description": "MCP server + status-line/hook reporters for Zopkit wrapper bug reports: fetch full bug context (with screenshots), submit how a bug was fixed, list bugs assigned to you, file new bug reports, and report REAL Claude Code usage \u2014 live per-session context and account rate limits via the status line, plus per-bug token attribution via PostToolUse hooks. Requires a BUG_REPORT_API_KEY (generated in the company-admin panel) \u2014 see README.md.",
   "license": "UNLICENSED",