# Reported issues for AnkusDrive Pod holds 17 of 20 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 [AnkusDrive](/mcp/ankusdrive). ## Most discussed ### Agent loses airtight-shell invariant across iterative geometry edits ## Context While using the DriftPin MCP server to model a Makita router → Dewalt shop-vac adapter through an LLM agent (Claude Code, Opus 4.7), I observed a repeated failure mode that I don't think is solely the agent's fault — it's a class of problem where DriftPin's tool surface does not push the agent toward verifiable geometric invariants. Full transcript: https://gist.github.com/mpetne/16dc4d2119ce41a24faf3d2c449ee79d ## Failure pattern across three iterations Each iteration "fixed the… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/19) · 2026-06-04 · closed · external user · 5 comments ### macOS: no SU2 case builder, so "CFD degrades to SU2" is still aspirational (#237 item 3) Found by the agent-eval run of 2026-07-31 (`scratch/agent_evals/`). Affects the "prove it with a CFD solve" workflow (#222) on macOS specifically. ## Problem: on macOS, no built-in CFD case can actually solve — but every affordance says CFD is available Verified live on Apple Silicon with the Multipass VM **provisioned (OpenFOAM v2512 installed) and running**: 1. `solve_capabilities` reports the `cfd` family `any_available: true` (SU2 resolves natively), and `docs/MACOS.md` says *"CFD alone… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/237) · 2026-08-01 · closed · 2 comments ### Modeling: pocket/hole carry the #282 degenerate-cut warnings but have no `strict` escalation **Source:** follow-up from the #282 implementation (the audit it asked for found this and deliberately left it). ## Problem #282 taught the subtractive path to name its two degenerate outcomes. `_h_boolean_op` got the full treatment — `removed_volume`, `volume_ratio`, a `warnings` list, and a `strict: true` param that upgrades annihilation/miss to an error for scripted recipes (`driftpin/worker.py:2790`, `driftpin/worker.py:2834`). The audit found `pocket`/`hole` share the defect and they… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/287) · 2026-08-22 · closed · 1 comment ### add_primitive silently ignores name= — every test that names a primitive is naming nothing Found incidentally while building #234: a two-sided test asserting "a hand-modelled part called `M6Screw` must NOT receive a standard-part designation" failed, because the object was actually still labelled `Cylinder`. ## The problem `@handler("add_primitive")` in `driftpin/worker.py` accepts a `name` parameter by convention (callers pass it, and other `add_*` handlers honour it), but the handler contains no `name` or `Label` handling at all. The value is accepted and discarded, and the… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/246) · 2026-08-02 · closed · 1 comment ### em_fullwave waveguide_sweep: returns ok:true with nulls when port placement exceeds guide length **Environment (reproduced):** AnkusDrive 0.5.5 (main @ 17a90aa), macOS arm64, Python 3.14, openEMS source build `0.0.36.post1.dev206`. Runner `ankusdrive/em_fullwave_gpl_runner.py` driven directly over the stdin/stdout sentinel protocol. openEMS itself is fine; these are problems in how the runner sets up the case and in what the gate measures. ## Summary Ports sit at `10*mesh_res`–`15*mesh_res` from each end of the guide. When `cells_per_wl` is small, `mesh_res` grows until the port planes… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/403) · 2026-09-14 · closed · 0 comments ### em_fullwave dipole_s11: mesh resolution is coupled to f_stop, so the resonance depends on the sweep window **Environment (reproduced):** AnkusDrive 0.5.5 (main @ 17a90aa), macOS arm64, Python 3.14, openEMS source build `0.0.36.post1.dev206`. Runner `ankusdrive/em_fullwave_gpl_runner.py` driven directly over the stdin/stdout sentinel protocol. openEMS itself is fine; these are problems in how the runner sets up the case and in what the gate measures. ## Summary In `_dipole_s11`, `mesh_res = lam0/30` with `lam0 = C0/f_stop`. `f_stop` also sets the Gaussian excitation (`f0=(f_start+f_stop)/2`,… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/400) · 2026-09-14 · closed · 0 comments ### em_fullwave dipole_s11: radius_mm and gap_mm are inert — both are below mesh resolution **Environment (reproduced):** AnkusDrive 0.5.5 (main @ 17a90aa), macOS arm64, Python 3.14, openEMS source build `0.0.36.post1.dev206`. Runner `ankusdrive/em_fullwave_gpl_runner.py` driven directly over the stdin/stdout sentinel protocol. openEMS itself is fine; these are problems in how the runner sets up the case and in what the gate measures. ## Summary `_dipole_s11` accepts `radius_mm` and `gap_mm`, but the mesh never gets extra lines at either feature, so neither one changes the result.… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/399) · 2026-09-14 · closed · 0 comments ### em_fullwave: fc_ratio compares the port's analytic cutoff to itself — it is not an FDTD gate **Environment (reproduced):** AnkusDrive 0.5.5 (main @ 17a90aa), macOS arm64, Python 3.14, openEMS source build `0.0.36.post1.dev206`. Runner `ankusdrive/em_fullwave_gpl_runner.py` driven directly over the stdin/stdout sentinel protocol. openEMS itself is fine; these are problems in how the runner sets up the case and in what the gate measures. ## Summary `_waveguide_sweep` reports `fc_ratio = fc_crossing_ghz / fc_analytic_ghz`. The runner docstring, the `em_fullwave_submit` handler and the… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/398) · 2026-09-14 · closed · 0 comments ## Most recent ### setup_status / doctor install hints are wrong inside the MCPB bundle Found while verifying the MCPB bundle (#346) in Claude Desktop, 2026-09-12. ## The defect `setup_status` and `ankusdrive doctor` recommend commands like: ``` pip install 'ankusdrive[mbd]' # mujoco pip install 'ankusdrive[topology]' # topopt/solidspy pip install 'ankusdrive[optics]' # rayoptics + optiland ``` When AnkusDrive runs from the `.mcpb` bundle, none of these can work: - The server's interpreter is a **uv-managed `.venv` inside Claude's extension directory**… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/347) · 2026-09-12 · closed · 0 comments ### Tests: test_mcp_boot.py skips on the self-hosted Linux lane, so #279's boot check has never run there **Source:** found while wiring `test_mcp.py` into CI for #288 — reading the job logs rather than trusting the green checkmarks. ## Problem `tests/test_mcp_boot.py` is the test #279 was written to produce: proof that an interpreter can *serve* MCP over stdio, with FreeCAD deliberately unresolved, so "MCP is broken" stays distinguishable from "FreeCAD isn't found". On the self-hosted Linux lane it has never run. From the `Test suite (FreeCAD 1.1, self-hosted)` job: ``` SKIP test_mcp_boot — the… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/317) · 2026-08-30 · open · 0 comments ### fem_run blocks the MCP channel — route it through the submit→poll job pattern `fem_run` is the last long-running solve that still blocks the MCP channel. Its own docstring says so: ``` ankusdrive/mcp_server.py:3512 def fem_run(analysis, workdir="/tmp/ankusdrive_fem") -> dict: """Run the CalculiX solver on an analysis. Blocks until the solve finishes. ``` Every other heavy family has already moved to the submit→poll job pattern — `study_submit`, `optimize_submit`, `cfd_*_submit`, `molding_fill_submit`, `acoustic_fem_submit`, `em_fullwave_submit` — with `job_status`… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/308) · 2026-08-30 · closed · 0 comments ### Install: Windows first-run path failed for a real user (Python 3.14, manual README steps) — harden the quickstart **Source:** external install report (2026-08-13, Windows 11 Home build 26200, Python 3.14). ## What happened The reporter followed the README steps manually on Windows: installed FreeCAD fine, but "had some issues with the MCP step" and eventually **gave up on the local install entirely** — downloaded the repo zip and had Claude Cowork build a cloud Ubuntu 24.04 / Python 3.11 sandbox instead. The local Windows install never succeeded. Contributing factors identified or suspected: 1. **mcp… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/279) · 2026-08-13 · closed · 0 comments ### Install: `driftpin doctor` should preflight the MCP server import, not just FreeCAD/solvers **Source:** external install report (2026-08-13). ## Problem In the field report, `driftpin ping` and `driftpin doctor` both **passed** while `driftpin mcp` was completely broken (mcp 2.0.0 ImportError — see companion issue "unpinned mcp dependency"). The CLI paths never import the `mcp` package, so `doctor` certified an install whose entire reason for existing — serving 240+ MCP tools to an LLM client — did not work. This is the silent-default defect class again: an absence (working MCP… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/278) · 2026-08-13 · closed · 0 comments ### Bug: unpinned `mcp` dependency — mcp 2.0.0 breaks `driftpin mcp` with `No module named 'mcp.server.fastmcp'` **Source:** external install report (2026-08-13, cloud sandbox: Ubuntu 24.04, Python 3.11, DriftPin 0.4.0, FreeCAD 1.1.3 AppImage). ## What happens `pyproject.toml` declares `"mcp>=1.2"` with no upper bound (`pyproject.toml:54`). A fresh `pip install` today resolves **mcp 2.0.0**, whose server module was restructured — `mcp.server.fastmcp.FastMCP` no longer exists. Result: - `driftpin mcp` fails immediately: `ImportError: No module named 'mcp.server.fastmcp'` (import at… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/277) · 2026-08-13 · closed · 0 comments ### slice_estimate MCP tool omits density_g_cc/filament_dia_mm — same unfollowable error as #238 Found by the wrapper-drift audit done while fixing #238 (PR #263). Same failure mode, same layer, different tool — and the only other hit in an AST sweep of all 281 MCP tools. ## Problem `driftpin/analysis/slicing.py::slice_estimate` takes `filament_dia_mm: float = 1.75` and `density_g_cc: float | None = None`. The worker handler at `driftpin/worker.py:13614` forwards `**p`. The FastMCP wrapper at `driftpin/mcp_server.py:6713` exposes **neither** — it forwards a fixed eight kwargs. So… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/264) · 2026-08-04 · closed · 0 comments ### add_primitive silently ignores name= (44 call sites naming nothing) Found while building #234's two-sided designation test ("a hand-modelled part called `M6Screw` must NOT get a designation") — the test failed because the object wasn't actually called that. ## Problem `@handler("add_primitive")` in `driftpin/worker.py` never reads `p.get("name")`, and the `add_primitive` MCP tool in `driftpin/mcp_server.py` has no `name` parameter at all. Callers passing `name=` get no error and no name — the object's `Label` stays `Box` / `Cylinder` / `Sphere`. 44 call… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/247) · 2026-08-02 · closed · 0 comments ### cost_estimate MCP tool omits price_usd_kg/density_kg_m3 — its own error message is unfollowable Found by the agent-eval prep of 2026-07-31 (`scratch/agent_evals/`): a direct MCP call `cost_estimate(volume_mm3=30429, material="aluminum", ...)` fails with ``` ValueError: no price for 'aluminum'; pass price_usd_kg ``` ## Problem The error's instruction cannot be followed over MCP. `driftpin/analysis/cost.py::cost_estimate` accepts `price_usd_kg` (and `density_kg_m3`) overrides, and the worker handler forwards `**p` — but the FastMCP wrapper's signature… [Read the thread](https://github.com/gchen19/AnkusDrive/issues/238) · 2026-08-01 · closed · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/gchen19/AnkusDrive/issues).