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.

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 · 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 · 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 · 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):

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 · 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).