# Reported issues for Carrick Pod holds 19 of 50 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 [Carrick](/mcp/carrick). ## Most discussed ### Warm rescan with deps installed takes 15 min, not 8: per-service analysis doubled and every service pays an 8 s floor Measured on the 0.3.43 warm rescan of the trig-bench main mirror (run 34113201399, tree `c139515d`, deps installed, `Sidecar ready`, 0 files sent to the analyzer on all 33 services). #748 and #751 did what they said: the sidecar came up in 0.5 s over the installed tree and every `Discovered N file(s) ... in 0.0s` line reads 0.0 s. The run still took **15 min 19 s** against 8 min on 0.3.41 for the same tree, and the difference is now all inside per-service analysis. | phase | 0.3.41 (run… [Read the thread](https://github.com/carrick-tools/carrick/issues/767) · 2026-09-07 · closed · 7 comments ### A run that fails before start-scan (Deno missing) leaves no cloud record: no scan-failed, no run log, no alert Found by the #1094 observability smoke (2026-09-15, build d98850f, fixture smoke-deno-onboarding, cloud 0.4.0+b3d64f52). With `deno` absent from PATH, `deno_support::require_runtime` (`src/main.rs:226`) fails before the sidecar spawns and before `run_analysis_engine_with_sidecar` is called. That function is the only place #1094 wraps `report_scan_failure` / `upload_run_logs` (`src/engine/mod.rs`). The run calls `resolve-repos` only, never `start-scan`, so no `scan_id` exists: no `scan-failed`… [Read the thread](https://github.com/carrick-tools/carrick/issues/1096) · 2026-09-15 · closed · 4 comments ### Vendored pnpm and tsc are looked for at a path only a checkout has, so an npm install loses every type verdict Found while packaging the CLI as an npm package (#710, PR #832). It is not a packaging bug: it is the one thing that stops a published `carrick` from producing a type verdict at all. ## What happens `src/sidecar/src/capture/check.ts`: ```ts function sidecarRoot(): string { // dist/src/capture/check.js -> up three -> sidecar root. const here = path.dirname(fileURLToPath(import.meta.url)); return path.resolve(here, '..', '..', '..'); } function binPath(name: string): string { return… [Read the thread](https://github.com/carrick-tools/carrick/issues/833) · 2026-09-08 · closed · 4 comments ### init: --project moves repos into the project before anyone confirms, including repos the user would have deselected `carrick init -w --project ` moved two repos out of their current projects and into `` as its first act, then printed the repo proposal, then stopped because there was no terminal (`use --yes to accept this proposal without a terminal`). The moves were already done on the server; nothing was written locally. Observed 2026-09-20 on 0.3.82, workspace folder holding several sibling repos. Output, in order: " is currently in project A" / "Moved into project… [Read the thread](https://github.com/carrick-tools/carrick/issues/1338) · 2026-09-20 · closed · 3 comments ### An `any` caused by an unresolvable import is labelled "declared that way in the source" **Severity:** S1 (wrong answer) ## Symptom `get_endpoint_types` says "`id` is `any`, declared that way in the source" on 26 rows. Nothing declares `any`: the ORM model import is unresolvable (the generated client is absent), and capture recorded "dangling internal specifier" on 22 aliases. An agent told the type is declared `any` stops looking instead of running codegen. ## Root cause (read) `capture/deep-walk.ts` `provenanceOf` marks every non-budget finding `declared`. ## Fix When the… [Read the thread](https://github.com/carrick-tools/carrick/issues/1164) · 2026-09-15 · closed · 2 comments ### Served signatures and type strings contain absolute machine paths (home directory, Deno npm cache, checkout root) **Severity:** S1 (wrong answer, privacy) ## Symptom Signatures read `import("/Users//Library/Caches/deno/npm/registry.npmjs.org/hono/4.12.12/...").Context<...>`. The index is shared with every workspace member and served through MCP, so this leaks the scanning user's account name and layout. It also inflates responses: about 70% of the bytes of one router's compact rows. ## Measured api has 258 signatures with it, launch 123, pdf-service 11. In a bare client, `return_type` /… [Read the thread](https://github.com/carrick-tools/carrick/issues/1160) · 2026-09-15 · closed · 2 comments ### call_graph: an import through a path alias (Deno import map `@/`, tsconfig `paths`) resolves to no call edge, so get_callers misses every caller that uses the alias Refs #474, #934, #931. `get_callers` reads `function_definitions[].calls` from the blob and inverts it (carrick-cloud `lambdas/mcp-server/src/tools/get-callers.ts`, `flattenIndex` + `callsTo`). The cloud side is a faithful inversion; the edges are missing in the blob. `call_graph` resolves an import only when the specifier is relative (`./`, `../`) or names a workspace package. A path alias (`@/x.ts` from a Deno import map, or `@/x` from tsconfig `paths`) is neither, so every call to a… [Read the thread](https://github.com/carrick-tools/carrick/issues/1104) · 2026-09-15 · closed · 2 comments ### The five platform packages published private, so an install of carrick lands with no binary Release 0.3.53 published all six packages and the `publish` job succeeded. Five of them are not readable by anyone. ## What is true The publish job printed, for each of the five, `Publishing to https://registry.npmjs.org/ with tag latest and public access`, a signed provenance statement, and `+ @carrick-tools/cli--@0.3.53`. The registry's own endpoint, unauthenticated: ``` $ curl -s https://registry.npmjs.org/@carrick-tools%2fcli-darwin-arm64 {"error":"Not found"} #… [Read the thread](https://github.com/carrick-tools/carrick/issues/884) · 2026-09-09 · closed · 2 comments ## Most recent ### init: nine rough edges from the owner's first run of 0.3.83 on a folder of repos The owner ran `carrick init` (0.3.83) in a real terminal on a folder holding five sibling repos on 2026-09-20, then `carrick doctor`. The flow worked — selection first, nothing written before the yes, the excludes persisted. Nine rough edges came out of that run, plus the session-start hook's size. One PR. ### 1. The repo picker preselects everything, and the hint does not say what a row's state is Every repo arrived selected and two had to be deselected; with "space to select" a highlighted… [Read the thread](https://github.com/carrick-tools/carrick/issues/1365) · 2026-09-20 · closed · 1 comment ### hooks: a Codex hook we write runs only after two approvals we cannot see Found while proving delivery for #1335 (PR #1339), against codex-cli 0.154.0 and its source. `carrick init` now writes `.codex/hooks.json`, and two states can leave that file inert with nothing in our output saying so. 1. **Hook trust.** A project hook is `Untrusted` until Codex records its hash, and `discover_handlers` pushes a handler only when it is `Trusted` or `Managed` (`codex-rs/hooks/src/engine/discovery.rs`, `hook_trust_status`). Codex asks at its next start. `carrick init` says this… [Read the thread](https://github.com/carrick-tools/carrick/issues/1346) · 2026-09-20 · open · 0 comments ### hooks: Codex has no SessionStart entry, so a resumed Codex session re-orients on nothing Follow-up to #1335 / #1339, which wrote `.codex/hooks.json` with the two entries the reuse nudge needs (`PostToolUse` on `apply_patch`, `UserPromptSubmit`) and nothing else. Claude Code also gets a `SessionStart` entry, which is one read of the index for a session that has been resumed, cleared or compacted. Codex accepts `additionalContext` on `SessionStart` too (`codex-rs/hooks/src/engine/discovery.rs` lists it among the five events that can), so the entry would work there as written —… [Read the thread](https://github.com/carrick-tools/carrick/issues/1345) · 2026-09-20 · open · 0 comments ### init: a repo left out of the selection is still reached by the folder's hooks, refresh and the next run carrick#1338 added a repo selection step to `carrick init`: in a folder of sibling repos the terminal picks which repos the install covers, and the proposal, the project question, the assignment and the connection are all scoped to that choice. The choice is not persisted, and three things still reach a repo that was left out. - **The next run asks again.** Nothing records the answer, so `carrick init` in that folder re-derives every repo and the reader has to deselect the same one each time.… [Read the thread](https://github.com/carrick-tools/carrick/issues/1344) · 2026-09-20 · open · 1 comment ### hooks: Codex parity for the end-of-task reuse nudge Follow-up to #1330, which shipped the nudge for Claude Code only. The ruling of 2026-09-20 asked for Codex parity; this is what is in the way, read out of Codex's own source rather than guessed. ## What ships today - `carrick check --recheck` answers with `recheck.new_functions`. - `carrick hook post-edit` records them per session under `~/.carrick/sessions/`. - `carrick hook stop` names the set once through `hookSpecificOutput.additionalContext`, which Claude Code delivers to the model while… [Read the thread](https://github.com/carrick-tools/carrick/issues/1335) · 2026-09-20 · open · 1 comment ### init: a package upgrade leaves the installed hooks and skills at the old version, and nothing says so Files written by `carrick init` (hooks in the agent settings, the task skills under `.claude/skills/` and `.agents/skills/`, the MCP entry) are only refreshed when someone runs `carrick init` again. `npm install -g carrick@latest` changes the binary and nothing else, so a repo keeps the hook text and skill bodies of whichever version first ran init. The user is never told. Seen on our own machines on 2026-09-20: global CLI at 0.3.68 with npm at 0.3.81, none of our repos carrying the four task… [Read the thread](https://github.com/carrick-tools/carrick/issues/1333) · 2026-09-20 · open · 1 comment ### Capture stubs keep absolute package specifiers on layouts the #1174 rewrite does not recognise **Severity:** S2 (privacy on laptop scans) ## Symptom #1174 (PR #1199) rewrites an absolute specifier in a capture stub's declaration files into the package's bare specifier. It recognises only two shapes: - a POSIX absolute path (`import("/...")`); - a package root at `node_modules/` or at `/`, the layout of a runtime's npm cache. A path in any other layout still ships in the stub exactly as printed, and it carries the checkout root or the home directory: - a Windows… [Read the thread](https://github.com/carrick-tools/carrick/issues/1203) · 2026-09-15 · open · 0 comments ### GraphQL documents against an external schema are not listed as external call candidates Follow-up to #1134 (PR #1177). Since #1177, a GraphQL document written against a committed schema that no service in the repository serves is left out of the index. The same applies to a document whose schema cannot be settled. The scan report counts both. The operations no longer appear anywhere an agent can query: they are not call rows and not in `list_external_calls`. Example: `apps/web/src/graphql/ledger.gql` sends `query Balance { balance }` against… [Read the thread](https://github.com/carrick-tools/carrick/issues/1187) · 2026-09-15 · open · 0 comments ### Capture stub declaration files keep absolute import("...") specifiers into node_modules **Severity:** S2 (privacy, and a specifier that cannot resolve off the scanning machine) ## Symptom A capture stub's `types/surface.d.ts` can carry a node-builder print such as `import("/node_modules/.deno/@/node_modules//index").JSX.Element`. The served-text scrub from #1160 deliberately leaves the stub's declaration files alone, because they are compiled again at check time, so the absolute path ships in the blob. Measured on the 2026-09-15 audit fixture: 2… [Read the thread](https://github.com/carrick-tools/carrick/issues/1174) · 2026-09-15 · closed · 1 comment ### npm shim ignores CARRICK_BIN for index/touch/check/refresh/derive/status and silently runs the installed binary `npm/carrick/bin/carrick.mjs` `runNative()` (line ~47, the path for `index`, `touch`, `check`, `refresh`, `derive`, `status`) resolves the binary with `resolveNativeBinary()` and never reads `CARRICK_BIN`. Only `pointAtNativeBinary()` (line ~78, hook/lsp/mcp-server) honours it. So `CARRICK_BIN=/path/to/build carrick index` runs whatever platform binary npm installed, with no warning. Found in the 2026-09-15 observability smoke: three of four runs meant for a local #1094 build ran a globally… [Read the thread](https://github.com/carrick-tools/carrick/issues/1100) · 2026-09-15 · closed · 0 comments ### Run-log redaction only replaces the literal home path; paths outside it can still name the account ## What happens `logging::redact_log` (carrick#1063) replaces the literal `$HOME` string with `~` before a laptop run log is uploaded. Any path that names the account without starting with that exact string is shipped as is: - a checkout outside the home directory whose path still carries the account name (for example a temp directory a tool derives from the home path, with `/` turned into `-`); - a home reached through a different spelling after canonicalisation (a symlinked or firmlinked… [Read the thread](https://github.com/carrick-tools/carrick/issues/1098) · 2026-09-15 · closed · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/carrick-tools/carrick/issues).