[Bug]: pi-fff registers tools before startup mode is known

[XWIlluDelu]

What happens

pi-fff resolves its startup options and registers its tools while the extension is loading. At that point Pi has registered the extension flags, but has not populated their values yet. Saved fff-mode entries arrive later, in session_start, after the tool names have already been chosen.

On current main (be2dd8d), an isolated Pi session shows both sides of the problem:

$ pi --fff-mode override
/fff-mode
Current mode: 'tools-and-ui' (flag: override)

The active extension tools are still ffgrep and fffind, rather than the expected grep and find overrides.

A session with a saved override selection has the opposite mismatch:

Current mode: 'override' (flag: unset)
Active extension tools: ffgrep, fffind

This is the mismatch noted in the review of #790: #790 (comment)

The timing also affects the other public CLI flags. The database paths and scan options call the same getConfigValue() helper before Pi makes flag values available, so their CLI values are skipped during initial construction.

Suggested fix

Keep flag registration where it is, but defer startup resolution and tool registration until session_start:

1. Resolve the five startup options after Pi has populated the flags.
2. Restore the saved session mode, preserving the current session-persistence behavior.
3. Create the finder factories and register the tools from that final state.
4. Explicitly activate the dynamically registered tool names.

For /fff-mode, switches between tools-and-ui and tools-only can remain immediate because their tool names are identical. A switch to or from override should save the selection but leave the reported active mode unchanged until /reload; that avoids another transient mismatch.

I have a focused patch ready on a fork. It keeps the tool definitions in place, queues only their final registration, and covers CLI precedence, saved-mode restoration, tool names, prompt guidelines, and the reload boundary. It passes the 74 pi-fff tests, type checking, formatting, and isolated Pi RPC checks. Happy to open the PR if this direction looks right.

[gustav-fff]

[triage-bot] REPRODUCED: Reproduced on origin/main (be2dd8d).

Diagnosis is worse than described. There are two independent failures, not one.

1. getFlag() is called before registerFlag(). getConfigValue() runs at packages/pi-fff/src/index.ts:331-370, but the flags are registered at packages/pi-fff/src/index.ts:582-607. pi returns undefined for unregistered names, early, before it ever looks at a value:

// pi-coding-agent/dist/core/extensions/loader.js:256-260
getFlag(name) {
    runtime.assertActive();
    if (!extension.flags.has(name))
        return undefined;
    return runtime.flagValues.get(name);
}

So all five flags are dead at load time regardless of value population.

2. Values land after the factory returns. applyExtensionFlagValues() writes argv into runtime.flagValues in dist/core/agent-session-services.js:8-45, which runs after the extension factory. Reordering registerFlag alone fixes nothing. Deferral is required.

Repro, no model call needed:

mkdir -p /tmp/fff-792 && cd /tmp/fff-792
printf '%s\n' '{"id":"1","type":"prompt","message":"/fff-mode"}' \
  | FFF_ENABLE_HOME_SCAN=0 timeout 40 pi --mode rpc --no-session \
      -e /path/to/fff/packages/pi-fff/src/index.ts --fff-mode override

Expected Current mode: 'override' (flag: override), actual:

Current mode: 'tools-and-ui' (flag: override)

Same for --fff-frecency-db /flag/frecency — finder is constructed with the default ~/.cache/nvim/fff_nvim instead.

The 72 tests pass because createPi() in packages/pi-fff/test/extension.test.ts:102-122 mocks getFlag to answer immediately, so it models neither ordering constraint. Any regression test needs a harness that gates getFlag on registerFlag and applies argv only after the factory returns.

Your suggested direction is correct and I verified it is safe. bindExtensions() runs _applyExtensionBindings() (which calls runner.bindCore()) before emitting session_start — dist/core/agent-session.js:1760-1761. So registerTool() in session_start is post-bind, runtime.refreshTools() is live rather than the load-time no-op, and _refreshToolRegistry() auto-activates any name not already in the registry (dist/core/agent-session.js:2010-2015). For override the names shadow the builtins at dist/core/tools/grep.js:79 and dist/core/tools/find.js:79, which are already active, so that path works too. Your explicit activation step is still worth keeping for the case where a builtin was excluded via -xt.

Not opening a PR — you have a tested patch and asked for a go-ahead, no point burning @dmtrKovalenko's review on two. Send it.

Honk-Honk 🪿

[XWIlluDelu]

Thanks for confirming both timing constraints. I opened #793. The test harness now gates getFlag() on flag registration and on the post-factory lifecycle step, and the patch keeps explicit activation for the -xt case you noted.