Problem
The Pi harness (@ai-sdk/harness-pi) hardcodes a per-session temp directory for AuthStorage, ModelRegistry, and uses SettingsManager.inMemory(). This means the harness cannot reuse a user's existing CLI login (~/.pi/agent/auth.json), model config (models.json), or settings (settings.json including defaultProvider/defaultModel).
When embedding the Pi harness in a host application that wants to reuse the user's interactive CLI credentials (zero-setup auth), there is no way to point the harness at the user's agent directory.
Proposed Solution
Add an optional agentDir field to PiHarnessSettings and CreatePiSessionInput. When provided, the harness constructs AuthStorage, ModelRegistry, and SettingsManager against that directory instead of the temp dir. When omitted, behavior is unchanged (temp dir + inMemory settings) — purely additive, non-breaking.
This gives the caller control over where Pi reads its global config from, without changing the default behavior for existing users.
Problem
The Pi harness (
@ai-sdk/harness-pi) hardcodes a per-session temp directory forAuthStorage,ModelRegistry, and usesSettingsManager.inMemory(). This means the harness cannot reuse a user's existing CLI login (~/.pi/agent/auth.json), model config (models.json), or settings (settings.jsonincludingdefaultProvider/defaultModel).When embedding the Pi harness in a host application that wants to reuse the user's interactive CLI credentials (zero-setup auth), there is no way to point the harness at the user's agent directory.
Proposed Solution
Add an optional
agentDirfield toPiHarnessSettingsandCreatePiSessionInput. When provided, the harness constructsAuthStorage,ModelRegistry, andSettingsManageragainst that directory instead of the temp dir. When omitted, behavior is unchanged (temp dir +inMemorysettings) — purely additive, non-breaking.This gives the caller control over where Pi reads its global config from, without changing the default behavior for existing users.