Pi workspace provider override hides global config and omits reasoning capability

[dbydd]

Summary

The Pi workspace provider integration currently has two related configuration-layer problems:

1. Once OpenAlice creates <workspace>/.pi-agent, composeEnv() sets PI_CODING_AGENT_DIR to that directory. Pi then treats it as the complete agent directory, so user-level Pi package declarations, settings, and other agent-dir resources from ~/.pi/agent are no longer loaded.
2. OpenAlice generates .pi-agent/models.json with only id and optional contextWindow. It does not carry Pi's model-level reasoning capability, so reasoning-capable custom models are loaded as reasoning: false and Pi disables thinking-level controls.

These should be handled by the same global + workspace Pi configuration reconciliation path, rather than by copying global configuration into every Workspace template.

Environment

• OpenAlice 0.82.0-beta, commit 185f5f338f86b059745e509362c7a49d0ec42090
• Docker deployment, Linux arm64
• Bundled Pi 0.80.6
• Workspace provider using the openai-responses wire shape

Reproduction A: workspace override hides global Pi resources

1. Install/configure Pi packages and behavior in the normal user agent directory (~/.pi/agent).
2. Configure a Pi workspace provider in OpenAlice so that .pi-agent/models.json and .pi-agent/settings.json are created.
3. Start Pi through OpenAlice, or run Pi with PI_CODING_AGENT_DIR=<workspace>/.pi-agent.
4. Compare the loaded packages/settings with a normal Pi invocation using ~/.pi/agent.

Observed: the redirected invocation loads the workspace agent directory as a replacement. User-level package declarations and settings disappear unless they are manually repeated in the Workspace.

Expected: user-level Pi configuration remains the base layer, while OpenAlice's Workspace provider/model configuration is an additive Workspace override.

Reproduction B: generated model loses reasoning capability

OpenAlice currently generates a model entry equivalent to:

{
  "id": "some_model",
  "contextWindow": 256000
}

Using Pi RPC get_state without making an LLM request gives:

models.json reasoning absent -> model.reasoning=false, thinkingLevel=off
models.json reasoning=true   -> model.reasoning=true,  thinkingLevel=high

Adding the following field makes Pi expose and use its thinking-level controls:

{
  "id": "some_model",
  "contextWindow": 256000,
  "reasoning": true
}

This manual edit is not durable because piAdapter.writeAiConfig() rewrites the generated models.json.

Source locations

• src/workspaces/adapters/pi.ts: redirects the whole agent directory through PI_CODING_AGENT_DIR and generates .pi-agent/{models,settings}.json.
• src/workspaces/cli-adapter.ts: WorkspaceAiCred models endpoint/model/context, but has no model capability field for reasoning.
• src/workspaces/adapters/ai-config.spec.ts: currently asserts model entries containing only id and optional contextWindow.

Desired behavior

• Treat normal user-level Pi configuration as the base layer and OpenAlice Workspace configuration as an override. Global package declarations/settings should not need to be duplicated into every template or existing Workspace.
• Model reasoning support should be explicit and model-specific, not forced on for every custom model. OpenAlice should carry an optional reasoning capability through its central/default/Workspace config flow and write it into Pi's model entry.
• readAiConfig() / writeAiConfig() should round-trip the capability, and later UI/default credential reconciliation should not silently drop it.
• Resetting a Workspace provider should remove only OpenAlice-derived Workspace state and restore normal global behavior.
• Add coverage for both global + Workspace config composition and reasoning: true generation/round-trip.

Current workaround

A custom Workspace template can repeat global package paths/settings in project config, and reasoning: true can be added manually to .pi-agent/models.json. This works for current Workspaces but is brittle: existing Workspaces drift, global changes do not propagate, and later provider rewrites can discard the manual model field.

[luokerenx4]

Fixed on dev by #670 (merge commit cbfeb8bc). Thank you for the unusually precise reproduction — both symptoms came from the same incorrect abstraction boundary.

Root cause

OpenAlice used PI_CODING_AGENT_DIR=<workspace>/.pi-agent to make a Workspace-specific models.json visible to Pi. Pi correctly treats that variable as the complete agent directory, not as a project overlay, so OpenAlice accidentally replaced ~/.pi/agent and hid the user's packages, settings, auth, resources, trust, and sessions. The generated custom-model entry also had no model-capability field, so Pi correctly defaulted reasoning to false.

What changed

• OpenAlice no longer injects or rewrites PI_CODING_AGENT_DIR. An explicit value set by the user is still respected; otherwise Pi uses its normal ~/.pi/agent directory.
• Each Workspace provider is registered under a stable, namespaced openalice-workspace-* id in the normal Pi user models.json.
• The Workspace selects only that provider/model through Pi's native project layer at <workspace>/.pi/settings.json. We do not pass forced --provider / --model flags, so Pi's own project-to-global fallback remains intact.
• OpenAlice stores secret-free rollback metadata in <workspace>/.pi/openalice-provider.json. Reset restores the pre-existing project defaultProvider, defaultModel, and managed Windows shellPath, then removes only the OpenAlice-owned provider from the global registry.
• Workspace purge/recovery also removes the projected global provider, so deleted Workspaces do not leave registry entries behind.
• reasoning is now an explicit Pi-only model capability. It round-trips through saved default credentials, Workspace creation, later Workspace edits, adapter reads/writes, and the UI. Models that do not support reasoning remain false rather than being opted in globally.

Existing Workspace migration

Migration 0024_pi_native_workspace_config scans active and departed Workspaces for the old .pi-agent layout. Before changing one, it copies the complete tree into the OpenAlice migration backup area. It then:

• converts the old workspace provider to the namespaced global provider plus local .pi/settings.json selection;
• merges packages, sessions, resources, auth, trust, settings, other providers, unknown files, and symlinks into the real Pi agent directory;
• lets already-existing global data win on collisions;
• removes .pi-agent only after reconciliation succeeds.

If either the legacy store or the real global store is malformed, that Workspace is reported and its old .pi-agent tree is left in place for repair instead of blocking Alice startup or deleting state. The adapter can retry the migration on a later launch.

Verification performed

• repository TypeScript and Vitest suite: 325 files passed (1 skipped), 3202 tests passed (8 skipped);
• non-trading E2E: 30 passed (3 skipped);
• migration, concurrent global-provider writes, collision handling, reset rollback, lifecycle cleanup, credential defaults, and UI round-trip coverage;
• installed Pi 0.80.6 RPC smoke: selected the namespaced Workspace provider/model, reported the configured context window and reasoning: true, retained the global thinking level, and discovered both a global user skill and the Workspace project skill;
• packaged Electron managed-Pi smoke completed a structured headless reply and CLI side effect;
• demo UI walkthrough covered both the per-Workspace and new-Workspace-default reasoning controls with no browser console errors.

Could you please retry on a build containing cbfeb8bc, especially in the original Docker/Linux arm64 environment? The most useful confirmation would be:

1. a recognizable package/setting from the normal Pi agent directory is still active inside the OpenAlice Workspace;
2. Pi RPC get_state reports the openalice-workspace-* provider, the expected model, reasoning: true, and the expected thinking level;
3. changing the saved default affects newly created Workspaces, while a later manual Workspace edit remains local;
4. “Reset to global default” restores the prior project/global selection without losing global Pi state.

I am leaving this issue open for that external reproduction. If migration logs a “kept legacy Pi state” warning, please include the warning text and the shapes (with keys redacted) of the affected models.json / settings.json; the original tree and backup should still be present.