Daemon warm-path hangs indefinitely on PHP/WordPress repo (stalls at ~12 files, CPU pegged ~185%); gortex index works fine

[mopristas]

Summary

gortex daemon start hangs permanently when warming a PHP/WordPress plugin repo (~838 files). The daemon stalls at exactly 12 of 825 files with CPU pegged at ~185% indefinitely, blocking the shared daemon's status socket. The standalone indexer (gortex index <path>) processes the same repo fully in under 1 second (825 files / 9.4k nodes / 31k edges).

Version

gortex v0.47.0+775d8bb3
commit:  775d8bb3
built:   2026-06-16T22:36:07Z
go:      go1.26.4
os/arch: darwin/arm64

macOS 15.x, Apple Silicon (M-series).

Reproduction steps

1. Clone mirlindv/nauticdb (PHP/WordPress API stack, ~838 files, ~392 .php files, multiple custom plugins).
2. gortex track ~/nauticdb — repo appears in config.
3. gortex daemon start --detach
4. Watch daemon status: progress freezes at 12/825 files, CPU stays at ~185% indefinitely (verified after 15+ minutes — never advances).
5. Other repos in the same daemon (Go, PHP/WordPress yachtsummary at ~1.5k files) warm correctly.

gortex index ~/nauticdb succeeds immediately: 825 files indexed / 9.4k nodes / 31k edges / <1s.

Behaviour

• Daemon log shows serverstack: resolve-time LSP hot path stage is active when the hang begins.
• The hang appears tied to the live semantic enrichment path in the daemon warm phase — the standalone indexer (which skips live LSP enrichment) is unaffected.
• No progress messages after the stall point; the status socket becomes slow/unresponsive while CPU is pegged, poisoning the shared multi-repo daemon.

Repo structure (plugin directories in walk order, first ~12 files)

wp-content/plugins/
  ai-yacht-chat/       # first in alpha walk
  claw_api/
  custom_api/
  dma-merge-tool/
  dma_yachts_api/
  mo_filter/
  mo_yachtfolio_import/
  mo_yachtsummary_connector/
  nauticdb/            # core plugin
  ...

The stall is consistent at walk-order files 1-12 across multiple daemon restarts. The exact culprit file has not been isolated (each bisect attempt takes 5-15 minutes per test cycle with daemon restart risk).

Attempted workarounds

Workaround	Result
semantic: false + enrich_on_watch: false in per-repo .gortex.yaml	No effect — daemon ignores per-repo semantic toggle during warm phase
exclude: the three largest plugin dirs (mo_filter/, propscraper/, uploads/)	No effect
Cloning locally (vs. Google Drive mount)	Stall persists on local NVMe clone
gortex daemon install-service (launchd)	Unrelated breakage (TCC + EOF) — not relevant to this bug

No --no-semantic flag exists on daemon start (only on gortex mcp), so global semantic-off via CLI is not available.

Expected behaviour

The daemon should either:

1. Warm the repo (preferably respecting semantic: false in per-repo .gortex.yaml to skip LSP enrichment), or
2. Time-out the resolve-time enrichment for a single file and continue past it, rather than hanging the entire warm pass.

Impact

Cannot add this repo to the shared multi-repo daemon. Workaround: run gortex index <path> on-demand (works fine). Cross-repo call-graph queries can't include this codebase.

Additional context

• Three other repos in the same daemon warm cleanly: a Go app (~8.5k files), a PHP/WordPress site (~1.5k files / 19.8k nodes), a smaller WP site (~1.2k files / 19.8k nodes).
• The nauticdb PHP plugins contain some unusual patterns: MadelineProto IPC (Telegram gateway), a custom SCIP-like type system, and large auto-generated PHP files. One of these may be triggering an edge-case in the LSP resolve pass.
• Happy to share repo access or a minimal reproducer if helpful.

[zzet]

Hey @mopristas.

Happy to share repo access or a minimal reproducer if helpful.

For a fast and efficient fix, I need a setup to reproduce it. The repo or minimal reproducer will be extreamly useful.

[mopristas]

The repo is private and owned by another developer, but the files are cloned locally — here are the first 13 PHP files in alphabetical walk order (the window where the daemon stalls):

https://gist.github.com/mopristas/4197b74977df1488f60aa9cca600eb72

These cover ai-yacht-chat/ (7 files) and claw_api/ (6 files). The daemon consistently stalls within this set across multiple restarts. Let me know if you need more files or the full repo structure.

[mopristas]

Root cause found and fixed — closing the loop.

The daemon hang was caused by a combination of two issues:

1. .gitignore directory-negation not applied by the daemon. The repo used a wp-content/plugins/* blanket ignore + !wp-content/plugins/foo/ negation pattern to whitelist custom plugins. The daemon respects .gitignore but does NOT apply directory-level negation patterns — so it saw wp-content/plugins/* and skipped the entire plugin tree, indexing only 12 root/docs files. The standalone gortex index ignores .gitignore entirely, which is why it always succeeded at 825 files. This is likely worth noting in docs or fixing: the daemon and standalone indexer behave differently on .gitignore negation.

2. Stale daemon snapshot blocks fresh walks. Once the daemon had indexed 12 files and stored them in ~/.gortex/store/store.sqlite (file_mtimes table), subsequent restarts loaded the 12-file snapshot and reconciled with stale_files_reindexed: 0 — never discovering the other 813 files. Running gortex index (standalone) does NOT write to the daemon's store, so it can't prime it.

Fix: Removed the blanket wp-content/plugins/* ignore from .gitignore (all plugins in this repo are custom, so the whitelist logic was unnecessary). After clearing the stale store rows and restarting the daemon, it indexed all 825 files in ~10s with CPU at <10%.

Commit: mirlindv/nauticdb@6397f13

The daemon gitignore-negation issue may still affect other repos using similar patterns — worth a look if you get a chance.