…EFRESH trigger

Changes driven by an open-ended correctness audit:

- crawlError now tears the service down (dispose worker, delete
  from INSTANCES, reject pending searches + whenReady waiters), so a
  transient crawl failure no longer leaks a worker per attempt.
- dispose() now rejects whenReady() waiters with AbortError; previously
  callers awaiting whenReady() through a dispose could hang forever.
  Also reorders unsubscribe before posting 'dispose' so the in-process
  transport's synchronous exit cleanup can't beat the AbortError.
- worker.on('error') is wired, converting uncaught worker errors into
  a normal exit-cleanup path instead of re-throwing on the main process
  and crashing the CLI.
- useAtCompletion gains a monotonic refreshToken in its reducer state
  and effect deps, so REFRESH re-triggers the worker effect even when
  the status was already SEARCHING (previously a partial chunk arriving
  mid-search could not cause a re-run).
- Worker 'dispose' now closes parentPort instead of process.exit(0) so
  in-flight searchResult/searchError messages drain before shutdown.
- FileIndexCore.startCrawl preserves the allFiles reference on the
  cache-hit fallback path to keep concurrent search() iterations stable.
- dispose() races transport.terminate() against a 2s timeout so a
  faulted worker cannot hang shutdown.
- handleExit is now idempotent: if dispose() already set disposed=true,
  a subsequent worker exit won't double-reject pending/readyWaiters.

Added regression tests for whenReady-on-dispose rejection and for
post-dispose FileIndexService.for() creating a fresh instance.

…TANCES hygiene

- `optionsKey()` now hashes the .gitignore / .qwenignore contents via
  loadIgnoreRules().getFingerprint(). Editing those files produces a new
  key so the next `FileIndexService.for()` spawns a fresh worker instead
  of serving a stale cached snapshot with outdated ignore rules.
- `FileIndexService.for()` only memoises an instance that survived
  construction. If the Worker spawn errored synchronously and handleExit
  ran before INSTANCES ever had the key, a permanently-disposed instance
  would otherwise be cached for the lifetime of the process.
- `FileSearch.dispose?()` is now a (optional) part of the public
  interface; the recursive proxy delegates to `FileIndexService.dispose()`.
- `FileMessageHandler.clearFileSearchCache` calls `dispose()` when a
  workspace file create/delete fires so the worker's fzf index is
  rebuilt from disk instead of continuing to serve stale results.

Added regression tests: editing .gitignore mid-session invalidates the
singleton; disposed services don't pollute INSTANCES.

…ttern errors

- Wrap FileIndexCore construction at worker module-init in try/catch.
  A bad projectRoot (e.g. containing NUL) used to crash the worker
  before its message handler attached, leaving the main thread waiting
  forever. We now surface the failure as a normal crawlError / searchError
  so the service sees it on the next message.
- Validate reqId / pattern types on 'search' messages so a malformed
  IPC shape fails just the one request instead of the whole worker.
- filter() now catches picomatch compile errors and returns [] — typing
  an interim `foo[` (common mid-keystroke state) no longer surfaces as
  a TypeError to the UI; it's simply "no matches" until the pattern is
  well-formed.
- Worker error log trims to name+message instead of the full Error
  object, so a CLI transcript/wrapper doesn't capture absolute paths
  from the user's machine by default.

Added regression test: malformed glob pattern in core.search returns [].

…y eviction

- scripts/prepare-package.js now lists `fileIndexWorker.js` in the
  published tarball's `files` whitelist. Without this, `npm i -g` would
  produce an install missing the worker, and the first `@`-picker use
  would throw ERR_MODULE_NOT_FOUND at runtime. Release blocker.
- FileIndexService.for() now disposes any stale instance under a
  different key but the same projectRoot before creating a new one.
  When `.gitignore` is edited mid-session, the fingerprint change would
  otherwise leave the old worker pinned in INSTANCES forever — the
  auditor flagged this as a real leak even though the commit message
  for round 2 implied it was fixed.
- Dropped `__setIndexTransportFactory` from the public barrel; it's a
  test-only hook that shouldn't be part of the external API. Tests
  (and nothing else) can still import it from the module directly.
- `search()` on a disposed service now throws AbortError instead of a
  plain Error, matching how in-flight searches are rejected inside
  dispose().

Added regression tests: stale-key service is disposed and its `search()`
throws AbortError after .gitignore-driven eviction.

…nc throw

Round 4 switched `FileIndexService.search()` on a disposed instance
from `Error` to `AbortError` for notional consistency with how in-flight
searches are rejected inside `dispose()`. The audit correctly called
out that this silently breaks useAtCompletion: the hook's catch block
swallows `AbortError` as "user pressed ESC" and never dispatches the
ERROR state, so a crawlError-driven cascade (where dispose() is called
and the next search hits the sync guard) would leave the UI stuck in
SEARCHING forever.

In-flight rejections inside dispose() remain AbortError — those are
genuine cancellations. The post-dispose sync guard is caller misuse
and must surface as a plain Error to drive the ERROR branch.

…cators

Addresses post-audit UX feedback:

- AppContainer kicks FileIndexService.for(...) as soon as Config.initialize
  resolves. The worker crawl starts in the background before the user types
  `@`, so the first picker open usually finds a ready (or nearly-ready)
  singleton and returns results without any visible wait.
- useAtCompletion no longer flips isLoading on the INITIALIZE dispatch.
  A 200ms timer now arms during INITIALIZING too, so the "Loading
  suggestions..." placeholder only appears if the crawl/search is
  genuinely slow — the common pre-warmed path opens silently.
- Remove the global ConfigInitDisplay render in Composer. The top-of-screen
  "Initializing..." banner is no longer shown while Config/MCP finish
  setting up; the prompt renders without any boot-time placeholder.

Updated the two useAtCompletion tests that asserted the old flash-loading
behaviour to assert the steady-state (isLoading=false) instead.

Initially planned as P2 to replace fdir with ripgrep for the @-picker
crawl. Empirical benchmarking on two representative trees refuted the
premise:

  qwen-code (~2700 files)   fdir ~25ms  vs  rg (spawn+IPC) ~140ms
  node_modules (~48k files) fdir ~640ms vs  rg (spawn+IPC) ~1800ms

Even though `rg --files` is ~70ms in a shell, the child_process spawn
and stdout-pipe overhead from Node dominates for every tree size we
tested. Claude Code's speed almost certainly comes from being a native
binary with an in-process walker, not from shelling out to ripgrep.

The ripgrepCrawler implementation is kept for future re-evaluation on
very large trees or different platforms, and is reachable via the
`QWEN_FILESEARCH_USE_RG=1` env var. fdir remains the default.

Also: useAtCompletion tests now sort before asserting on suggestion
order. The exact ranking is an fzf tiebreak artifact that depends on
crawler emission order — not a behavioural contract worth coupling
tests to.

Earlier commit (21764b5) gated ripgrep off by default based on a
benchmark that only covered small-to-medium trees (<48k files), where
Node's spawn+IPC overhead does beat fdir. User-reported feedback
prompted a re-test on a home-directory-scale target:

  qwen-code repo (~2700 files)     fdir ~25ms   rg ~140ms   fdir wins
  project/node_modules (~48k)      fdir ~640ms  rg ~1800ms  fdir wins
  ~/ home dir (100k-file cap)      fdir ~9s     rg ~2.5s    rg 3-4× wins

The slow case is the painful one — a user typing @ at $HOME shouldn't
wait 9 seconds while Node's single-threaded walker catches up. On small
repos both backends are well below the 200ms loading threshold, so the
perceptual cost of rg's spawn overhead is zero. Flip the default; keep
`QWEN_FILESEARCH_USE_RG=0` as the escape hatch to force fdir.

Windows CI was failing the full filesearch suite (useAtCompletion,
crawler, fileSearch, fileIndexCore, fileIndexService) because ripgrep
on Windows emits `.\file.txt`; the stdout pump stripped `./` before
`toPosixPath`, so the leading `./` survived and the ancestor-directory
walk in `buildRipgrepFileFilter` asked the ignore lib to test `"./"` —
which throws RangeError and poisoned the data handler. Normalize to
posix first, then strip; guard the filter for `.`/`./`/leading-`./`
inputs as defence in depth.

Also addresses review feedback:

- fileIndexService: an early worker exit left `_state` at `'crawling'`,
  so a `whenReady()` call arriving after the exit parked in readyWaiters
  and never settled. `handleExit` now transitions to `'error'` so the
  state check rejects synchronously.
- AppContainer prewarm: guarded on `enableRecursiveFileSearch` so
  opted-out users don't pay for a full crawl + worker at startup.
- FileMessageHandler: added a per-rootPath generation token so an
  in-flight `initialize()` disposes the stale index instead of
  re-caching it when `clearFileSearchCache` fires mid-crawl.

Regression tests added for all four.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ata payloads

- Remove unused `buildCaseInsensitiveGlob` helper and its companion
  `globSpecialChars` Set. Both were carried over from an earlier
  case-insensitive-search attempt and have no callers anywhere in the
  tree.
- Switch `Record<string, unknown>` reads in the message handler
  (`data?.query`, `data.path`, `data.content`, etc.) to bracket syntax
  so the file stays clean under stricter
  `noPropertyAccessFromIndexSignature` variants of the TS config.

Pure cleanup; behaviour unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ng tmp

After the ripgrep path fix landed, the only remaining Windows CI
failures were `EBUSY: resource busy or locked, rmdir` on test temp
directories. Root cause: `ripgrep --files` is spawned with
`cwd: crawlDirectory`, and on Windows the OS holds a handle on that
working directory until the child fully exits. If `afterEach` calls
`cleanupTmpDir` before the FileIndexService (and its rg subprocess)
is disposed, rmdir races the handle release and fails.

Three-pronged fix:

- `cleanupTmpDir` now passes `maxRetries: 5, retryDelay: 100` to
  `fs.rm`. Node retries EBUSY/EPERM internally on Windows; half a
  second is plenty for tens-of-ms handle-release races. This is a
  blanket safety net for every caller.
- `fileIndexService.test.ts` afterEach: `__resetForTests()` runs
  before `cleanupTmpDir` so the transport is torn down first.
- `useAtCompletion.test.ts` afterEach: added the same
  `FileIndexService.__resetForTests()` call so the hook's in-process
  worker is disposed before the dir is removed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- fileIndexCore: drop the redundant second crawl() on cache hits; use
  the first call's return value when onProgress never fires.
- fileIndexProtocol: new module holding WorkerRequest/WorkerResponse so
  fileIndexService and fileIndexWorker can't silently diverge.
- fileIndexService: LRU cap (8) on the INSTANCES singleton Map; hits
  re-insert to refresh recency. Dispose timeout warns + retries
  terminate() as a force-kill fallback.
- fileIndexService: drop `process.env['VITEST']` transport sniffing in
  favour of an explicit `installInProcessIndexTransport()` DI hook
  wired from each package's test-setup. Survives bundling.
- crawler: `ripgrepDisabled` is now a timestamp with a 5-minute
  cooldown (was permanent-for-process-lifetime). A single spawn failure
  no longer downgrades long-lived hosts like the VSCode extension for
  the whole session.
- crawler: collectRipgrepExcludeDirs now forwards plain directory
  patterns (.git/, build/, user ignoreDirs) to rg as `--glob '!dir'`
  args so rg prunes subtrees at the walker instead of streaming every
  path under them for the Node post-filter to reject.
- useAtCompletion: fileSearchOptions is useMemo'd on [config, cwd] and
  both effects have it in their deps — the eslint-disables are gone.
  Extracted `buildFileSearchOptions(config, cwd)` helper that
  AppContainer uses too, so the prewarm and search paths can't drift
  from the same FileIndexService singleton key.

Tests:
- fileIndexService.test: new "evicts the oldest instance when the LRU
  cap is exceeded" regression test.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Conflict in packages/cli/src/ui/components/Composer.tsx: upstream added
`HistoryItemToolGroup` type import to support per-subagent token
attribution, while this branch removed the `ConfigInitDisplay` banner
as part of the pre-warm UX change. Resolved by keeping the upstream
type import and dropping `ConfigInitDisplay` (import + JSX usage),
which is the intended behaviour of this PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…imers

Addressing @wenshao's two findings on QwenLM#3455:

1. `--bare` mode tests failing in `packages/cli/src/config/config.test.ts`

   Root cause (correctly diagnosed): the top-level
   `installInProcessIndexTransport()` call in `test-setup.ts` eagerly
   evaluated `@qwen-code/qwen-code-core`'s module tree, pulling
   `workspaceContext.ts` in with a real `node:fs` binding. Later
   `vi.mock('fs', …)` declarations in individual test files no longer
   took effect, so `fs.existsSync()` fell through to the real FS and
   silently dropped mock directories.

   Fixed by removing the install from both `test-setup.ts` files and
   opt-ing in per-test-file (`beforeAll`/`afterAll`) in the three
   suites that actually exercise the worker-backed filesearch:

   - `packages/core/src/utils/filesearch/fileIndexService.test.ts`
   - `packages/core/src/utils/filesearch/fileSearch.test.ts`
     (also drops live singletons between tests so Windows rmdir
     doesn't race an open ripgrep child)
   - `packages/cli/src/ui/hooks/useAtCompletion.test.ts`

   The two `test-setup.ts` files now carry an explanatory comment so
   this doesn't regress.

2. CI matrix stuck for ~10h on "Run tests and generate reports"

   Likely cause: pending `setTimeout` handles keeping the event loop
   alive past test completion.

   - `FileIndexService.dispose()` raced `terminate()` against a 2 s
     `setTimeout` but never cleared the timer on the healthy-exit
     path — so after every disposal the process held a timer for up
     to 2 s. Now the terminate() arm clears the timer, and the
     timer is also `.unref()`'d as a belt-and-suspenders.
   - `crawlCache` TTL timers (default 30 s) are now `.unref()`'d
     too. They'd keep vitest workers waiting on exit even after
     all assertions passed.

   `clear()` still drops both synchronously between tests, so
   correctness is unchanged.

Verified:
- `npx vitest run src/config/config.test.ts -t "should ignore implicit startup"` now passes (was failing before).
- Full test suites — core 5925 / 5927, cli 4275 / 4282 (skipped tests pre-existing), vscode-ide-companion 204 / 205 — all green.
- Typecheck clean on core + cli.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>