Skip to main content
Glama

seamcheck

Find dead seams: code your tests exercise that nothing in production calls.

A dead seam is distinct from dead code. Dead code is reached by nothing and looks abandoned. A dead seam is reached by your test suite and by nothing else, so it looks finished: written, reviewed, green. A repository can hold a fully passing suite while its main loop cannot reach the organs the suite is guarding. Coverage will not tell you, because coverage asks whether tests reach code, never whether the application does. Review will not tell you, because the missing call site is an absence, and absences do not appear in diffs.

seamcheck asks the missing question directly. It finds your production entry points, walks the import graph, and reports every file that only your tests can reach.

Use

npx seamcheck .

Exit codes: 0 clean, 1 seams found, 2 scan error. Add --json for machine-readable output; the MCP server returns the same JSON.

The report has three verdicts. Alive: reachable from a production entry point. Dead seam: reachable only from test files. Dead code: reachable from nothing.

Related MCP server: agentguard

What a run looks like

Real output against the fixture repo this package tests itself with:

seamcheck v0.1.0
root: C:\Users\operator\projects\fixture
entry points (1): src/main.ts

DEAD SEAMS (1) — tests reach these; production cannot:
  src/seam.ts

DEAD CODE (1) — nothing reaches these at all:
  src/orphan.ts

summary: 3 alive, 1 seams, 1 dead, across 5 production files (1 test files).

Why suites lie about done: https://emberthread.dev/seams

Run against itself, seamcheck reports zero seams and zero dead files, which is the least it owes you.

MCP

The package ships an MCP server exposing one tool, scan_dead_seams, so a coding agent can run the scan on its own work mid-session. Configuration:

{ "mcpServers": { "seamcheck": { "command": "npx", "args": ["-y", "-p", "seamcheck", "seamcheck-mcp"] } } }

Seams found is a finding, not an error; the agent gets the same JSON as --json.

Entry points

seamcheck reads production roots from package.json (bin, main, module, exports), mapping built paths like dist/x.js back to their sources where it can. Add anything it cannot infer, such as route handlers registered by name or scheduled jobs, to .seamcheckrc.json:

{
  "entryPoints": ["src/jobs/nightly.ts"],
  "ignore": ["scripts/**"],
  "testPatterns": ["**/*.test.*", "**/*.spec.*", "**/__tests__/**", "**/test/**", "**/tests/**"]
}

Patterns support **, *, ?, and single-level {a,b} alternation. The entry point census is the one part of the scan that deserves your judgment. Everything after it is a mechanical walk.

Honesty

Version 0.1 classifies at file level over the static import graph, for TypeScript and JavaScript. Dynamic import() and require() calls with non-literal arguments are invisible to it; when they exist, the report says so and how many, rather than pretending the graph is complete. Files wired only through string-keyed registries can be misclassified: declare them as entry points or ignore them, and treat the note in the report as the tool admitting the limit of what it can see. Cross-package edges through installed or workspace dependencies are not traced yet either; in a monorepo, scan each package separately.

Prior art

knip's --production mode and unimported walk entry-point graphs too, and if they already work for you, keep them. seamcheck exists for one distinction they don't make: it separates dead seams (tests reach it, so it looks finished and actively misleads) from dead code (nothing reaches it, so it looks abandoned). That verdict is the point; the dangerous file is the one your suite is guarding. It also ships as an MCP tool so an agent can scan itself mid-session, which is the workflow it was built for.

Why this exists

This tool ships alongside a field manual on running persistent coding agents, written after a month of stalls in a project whose suite of 1,308 tests was green while 229 files sat unreachable from its main loop. The scan that ended that month took an afternoon to write. This is that afternoon, made general. The full anatomy of the defect class is a free chapter: https://emberthread.dev/seams — part of Running a Persistent Coding Agent, the field manual this tool ships with.

MIT © 2026 Emberthread

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides code analysis for Next.js projects through the Model Context Protocol, enabling IDE and LLM integration to identify unused files, dead code, and redundant API endpoints.
    4
    8
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables scanning of AI agent code for security vulnerabilities such as prompt injection, tool abuse, and data exfiltration, directly from MCP-compatible clients like Claude Code.
    2
    LGPL 3.0