[Bug]: Pi usage ignores the provider instance's home outside --session-dir launch arguments #34717

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.
• Removed credentials, tokens, private paths, and sensitive data.

Area

apps/server

Observed behavior

Source-only UI finding with a directly executed production-helper check: configure a Pi provider instance with an absolute HOME different from the T3 server's home, leave launch arguments empty, and keep Pi's default session directory. Pi receives the instance environment, but T3's usage reader resolves .pi/agent/sessions against the server's home. The same mismatch occurs for PI_CODING_AGENT_DIR=~/custom-pi and PI_CODING_AGENT_SESSION_DIR=~/custom-sessions. Recorded turns in the instance home are therefore outside the reader's scan roots, so the configured account's history is missing from Usage.

Reproduction

1. At release v0.1.9 in the repository root, run the following focused check. It extracts and executes the unchanged resolvePiSessionsDir and expandHomePath production functions with Node's TypeScript stripping. A child Node process confirms that the configured HOME controls native os.homedir(); no Pi process, network request, user file, or live T3 instance is used.

node --input-type=module <<'JS'
import fs from 'node:fs';
import path from 'node:path';
import vm from 'node:vm';
import { stripTypeScriptTypes } from 'node:module';
import { execFileSync } from 'node:child_process';
const repo = process.cwd();
const usage = fs.readFileSync(path.join(repo, 'packages/provider-pi/src/server/usage.ts'), 'utf8');
const expansion = fs.readFileSync(path.join(repo, 'packages/provider-core/src/server/pathExpansion.ts'), 'utf8');
const usageFunction = usage.slice(usage.indexOf('export function resolvePiSessionsDir('));
const expansionFunction = expansion.slice(expansion.indexOf('export function expandHomePath('));
const source = stripTypeScriptTypes(`${expansionFunction}\n${usageFunction}`.replaceAll('export function', 'function'));
const context = vm.createContext({ NodePath: path });
vm.runInContext(source, context);
const hostHome = '/fixture/host-home';
const instanceHome = '/fixture/instance-home';
const environment = { ...process.env, HOME: instanceHome };
const nativeHome = execFileSync(process.execPath, ['-e', 'process.stdout.write(require("node:os").homedir())'], { env: environment, encoding: 'utf8' });
for (const [name, extra, expected] of [
  ['default sessions', {}, path.join(nativeHome, '.pi/agent/sessions')],
  ['tilde agent directory', { PI_CODING_AGENT_DIR: '~/custom-pi' }, path.join(nativeHome, 'custom-pi/sessions')],
  ['tilde session directory', { PI_CODING_AGENT_SESSION_DIR: '~/custom-sessions' }, path.join(nativeHome, 'custom-sessions')],
  ['absolute workaround', { PI_CODING_AGENT_SESSION_DIR: '/fixture/instance-home/custom-sessions' }, '/fixture/instance-home/custom-sessions'],
]) {
  const actual = context.resolvePiSessionsDir({ HOME: instanceHome, ...extra }, hostHome, path);
  console.log(JSON.stringify({ name, expected, actual, matches: actual === expected }));
}
JS

The check ran once and deterministically returned the three mismatched paths below; the absolute-directory workaround matched. The user-facing scenario is traced from the supported settings and Usage RPC entry points, not run in a web, desktop, or mobile client. Proposed UI confirmation: configure Pi with HOME pointing to a separate absolute home, use a Pi session there, then open Usage and refresh; compare against its recorded session history.

Expected behavior

Usage should discover a configured Pi account's recorded native sessions in the same home the Pi process uses. The Usage guide promises each configured account's history and supports ~/ paths in account environment settings. Pi's getAgentDir and getSessionsDir derive the default directory from homedir(). T3 already uses the instance's platform-specific home for --session-dir ~/..., but not for its other supported session-directory forms.

Impact and scope

Impact: P2 - Configured Pi accounts using a separate process home have recorded usage omitted from the dashboard. The defect is bounded to these configurations, and an absolute PI_CODING_AGENT_SESSION_DIR is a safe path-resolution workaround confirmed by the helper check.

The helper mismatch was observed on Linux. The same resolver receives the host home on Windows, but a Windows runtime was not exercised: NOT_ENOUGH_INFO whether the native Pi Windows installation uses USERPROFILE for each supported installation mode; a Windows instance-home reproduction would establish that scope. No sessions are deleted, and normal Pi turns are not changed by this reporting defect.

Version

T3 Code release v0.1.9, source commit 24e77473ecf41bc1f7142529c7911c1c1aae1d76. A comparison against the fetched origin/main at 7462f234e89027943cf0d1a73d3ae1f36571d4e3 found no changes to packages/provider-pi/src/server/usage.ts. Pi was not installed or run; its native default path was traced from the pinned source reference above.

Runtime and platform

Focused production-helper check: Node.js v26.13.1, Linux, x64. No provider dependency installation or paid agent turn was needed. NOT_ENOUGH_INFO the affected installed Pi version range; reproducing in released Pi versions would establish it.

Interface

UI: Usage; server RPC server.getUsageSummary; Library: piUsageReader.directories and resolvePiSessionsDir.

Earliest failure stage

Setup or configuration

Relevant output or evidence

Actual helper-check output uses synthetic absolute fixture paths, not machine-local account paths:

{"name":"default sessions","expected":"/fixture/instance-home/.pi/agent/sessions","actual":"/fixture/host-home/.pi/agent/sessions","matches":false}
{"name":"tilde agent directory","expected":"/fixture/instance-home/custom-pi/sessions","actual":"/fixture/host-home/custom-pi/sessions","matches":false}
{"name":"tilde session directory","expected":"/fixture/instance-home/custom-sessions","actual":"/fixture/host-home/custom-sessions","matches":false}
{"name":"absolute workaround","expected":"/fixture/instance-home/custom-sessions","actual":"/fixture/instance-home/custom-sessions","matches":true}

The supported path is Usage RPC handler → per-instance environment merge and reader invocation → Pi directory callback. The callback reads the host home, separately derives launchHome for launch arguments, then passes the host home to resolvePiSessionsDir. The resolver does not consult environment.HOME or environment.USERPROFILE. HostProcess.HomeDirectory reads the T3 server process's os.homedir().

The native side preserves the configured environment: Pi adapter launch passes launch.env to the RPC connection, and the RPC process spawn uses that environment with extendEnv: false.

Additional context

Open and closed PR searches for "Pi" "usage" "HOME" and "resolvePiSessionsDir" found the related merged launch-directory PR listed under References, not a repair for the default and environment-directory paths reported here. The report concerns resolving the home for already-supported inputs, not discovering relative per-project paths or Pi's settings.json session-directory setting.

References

• Merged PR #30690 fixed the configured home for --session-dir ~/... launch arguments. The default and environment-directory paths reported here still use the server home, so they remain a distinct, unfixed scope.