# Reported issues for hunch by davesheffer

Pod holds 10 of 10 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to [hunch by davesheffer](/mcp/hunch-by-davesheffer).

## Most discussed

### hunch_task start throws ERR_MODULE_NOT_FOUND for 'tsx' on published installs since #254 (1.37.1, 1.38.0)

## Summary

Since #254, `hunch_task(action: "start")` fails on every installation where `tsx` is not resolvable — which is any plain `npm install -g @davesheffer/hunch`, because `tsx` is a **devDependency**:

```
Task report unavailable: Cannot find package 'tsx' imported from
  <prefix>/lib/node_modules/@davesheffer/hunch/dist/mcp/taskReportTools.js
```

Affects **1.37.1** and **1.38.0** (the two releases published after #254 merged).

## Cause

#254 moved the loader resolve *out* of the `dev`…

[Read the thread](https://github.com/davesheffer/hunch/issues/261) · 2026-09-16 · closed · outside contributor · 2 comments

### Tool results ignore the budget: hunch_context returns ~9k tokens for a 1.5k brief; hunch_findings is unbounded

## What was measured
`hunch_context("src/mcp/server.ts")` with the default `budget_tokens: 1500`:

- `content` text: 6,000 characters — exactly the budget.
- `structuredContent`: 30,348 characters (about 7.6k tokens). Of that, `omitted` is 21,047 characters: 104 entries, each repeating the same sentence ("only the top 2 decision hypotheses are delivered; refine the task evidence or inspect this record with hunch_why"). `text` (6,351) repeats the content text.
- Whole result: about 9.2k tokens.…

[Read the thread](https://github.com/davesheffer/hunch/issues/371) · 2026-09-20 · closed · outside contributor · 1 comment

### Per-prompt overhead: ~1.8k tokens of hook text and mandatory task start/finish

## What was measured
With the prompt hook installed, every user prompt costs, before any work:

- UserPromptSubmit hook text: about 1,130 characters (~300 tokens), identical on every prompt. One paragraph repeats the generic "Hunch is available…" guidance already in the grounding block; the other is the task-ID instruction from `src/core/taskReportHook.ts:139`.
- The instructed `hunch_task start` call: response ~250 tokens.
- The instructed `hunch_task finish` call: response ~1.2k tokens…

[Read the thread](https://github.com/davesheffer/hunch/issues/370) · 2026-09-20 · closed · outside contributor · 1 comment

### MCP tool list costs 12.7k–21.4k tokens on hosts that load every schema

## What was measured
`tools/list` over stdio returns 42 tools, 85,584 characters (about 21.4k tokens):

| field | chars | ~tokens |
|---|---|---|
| outputSchema (6 tools) | 30,441 | 7.6k |
| inputSchema | 30,066 | 7.5k |
| description | 18,136 | 4.5k |
| title + execution + name | 3,893 | 1.0k |

name + description + inputSchema alone is 50,866 characters (about 12.7k tokens). Largest tools: `hunch_context` ~4.0k, `hunch_change_proof` ~3.0k, `hunch_record_decision` ~1.1k, `hunch_shortlist`…

[Read the thread](https://github.com/davesheffer/hunch/issues/368) · 2026-09-20 · closed · outside contributor · 1 comment

### hunch_check_constraints and hunch_blast_radius return nothing for absolute paths

## Bug
`src/store/hunchStore.ts:1555` (`checkConstraints`) and `src/mcp/server.ts:510-517`, `:1020`, `:1064` match scope globs against the target as given. An agent passing the absolute path from its edit payload gets "No constraints in scope" even though a blocking `src/store/**` rule applies. `hunch_why` works on the same path because it matches by suffix, so grounding and planning tools disagree.

## Evidence
```
scope: [ 'src/store/**' ]
checkConstraints(rel): [ 'con_bd606fb786' ]…

[Read the thread](https://github.com/davesheffer/hunch/issues/296) · 2026-09-17 · closed · 1 comment

### hunch supersede (CLI) only looks in the public store

## Bug
`src/cli/index.ts:4265-4267` resolves both ids with `store.json.get` and calls `store.supersede` → `supersedeIn(this.json, …)` (`src/store/hunchStore.ts:1853`).

## Impact
- Shared (unified) mode: every decision lives in the overlay, so `hunch supersede <old> --by <new>` always fails with `--by decision "…" not found`.
- Private mode: overlay decisions cannot be superseded from the CLI.

The MCP path handles this correctly (`src/mcp/server.ts:1888`).

## Suggested fix
Resolve both ids…

[Read the thread](https://github.com/davesheffer/hunch/issues/294) · 2026-09-17 · closed · 1 comment

### hunch serve compact rewrites the ledger without the partition write lock

## Bug
`hunch serve compact` (`src/cli/serve.ts:70`) rewrites a partition's change ledger without taking the partition write lock.

`compactLedger` (`src/store/changeLedger.ts:152-160`) reads the ledger, slices events and writes it back. Every writer takes `withWriteLock` (`src/serve/app.ts:186`, `src/mcp/server.ts:2192`); compaction does not.

## Impact
Compacting while `hunch serve` or a stdio MCP writer is live:
- a write appends event N+1 and its idempotency entry between compaction's read…

[Read the thread](https://github.com/davesheffer/hunch/issues/286) · 2026-09-17 · closed · 1 comment

### mismatch: hunch_context parameter named 'target' but documented as 'target_or_task' in claudemd generator

In `@davesheffer/hunch` (tested on version `1.19.0` and earlier), there is a mismatch between the schema parameter name and the generated instructions for `hunch_context`.

Specifically, in `package/dist/mcp/server.js`, the `hunch_context` tool is registered with the following `inputSchema`:
```typescript
        inputSchema: {
            target: z.string().describe("A file path, symbol, or task phrase you're about to work on."),
            budget_tokens: z.number().optional().describe("Rough…

[Read the thread](https://github.com/davesheffer/hunch/issues/95) · 2026-08-28 · closed · external user · 1 comment

## Most recent

### Reused task id reopens a host-closed task and nothing closes it again

## Summary

`appendEvent` reopens a task whose `closed_by` is `host` on **any** new observation (state → `open`, `finished_at` → null). The grounding block tells agents to *"Reuse the ID for follow-up work on the same task"*, so on the next prompt an agent that passes the previous prompt's `task_id` to `hunch_context` reopens that host-closed task. No Stop for the old prompt id ever follows (Stop closes the *current* prompt's id), so the old task stays open forever, `taskRecordFromReports`…

[Read the thread](https://github.com/davesheffer/hunch/issues/266) · 2026-09-16 · closed · 0 comments

### Task stays open forever when a prompt ends without Stop (interrupt); its evidence never reaches the episode record

## Summary

In 1.38.0 the task is closed by the lifecycle **Stop** hook (`closeHookTask`). If a prompt ends without a Stop event, its task stays `open` forever, and none of its evidence reaches the episode's graph record. The most common case is a user interrupt or a quick re-prompt: Claude Code does not fire Stop when the user interrupts.

## Cause

1. `startHookReport` links the next prompt of the same session to the previous task (`continues` / `episode`), but it does not close that task if…

[Read the thread](https://github.com/davesheffer/hunch/issues/263) · 2026-09-16 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/davesheffer/hunch/issues).