bug: omp import by session id drops the session's model and thinking level (providerHandleId passed where a file path is expected)

[noamsiegel]

What's broken

paseo import <session-id> --provider omp discards the session's model and thinking level, and the created agent lands on a default model the user may not even have access to. Sending to that agent then fails.

OmpAgent.importSession passes input.providerHandleId straight into readOmpImportSessionConfig:

https://github.com/getpaseo/paseo/blob/main/packages/server/src/server/agent/providers/omp/agent.ts#L2361-L2367

async importSession(input: ImportProviderSessionInput, context: ImportProviderSessionContext) {
  const importConfig = await readOmpImportSessionConfig(input.providerHandleId);

but that function's parameter is a file path, not a handle id:

https://github.com/getpaseo/paseo/blob/main/packages/server/src/server/agent/providers/omp/session-descriptor.ts#L101-L106

export async function readOmpImportSessionConfig(
  filePath: string,
): Promise<OmpImportSessionConfig> {
  const descriptor = await readOmpSessionDescriptor(filePath);
  if (!descriptor) return {};

When the handle is a bare session UUID (which is what paseo import <id> supplies), the open fails, readOmpSessionDescriptor returns null, the config is {}, and importSessionFromPersistence creates the agent with no model and no thinking level. Importing by absolute session-file path takes the same code path and works correctly, which isolates the defect to the argument, not to the extraction logic.

This is distinct from #1440 (pi provider, closed) and it survives the extractModel fix at session-descriptor.ts:419-423 - that fix is correct and simply never runs on the id path.

Steps to reproduce

Any omp session whose model_change entry is not the default. Here anthropic/claude-opus-5:

$ jq -c 'select(.type=="model_change")' \
    ~/.omp/agent/sessions/--private-tmp-paseo-shim-test3--/2026-08-01T02-10-00-207Z_019fbb15-dd8f-7000-9922-4d962525d4e6.jsonl
{"type":"model_change","id":"00a79115","parentId":null,"timestamp":"2026-08-01T02:10:00.538Z","model":"anthropic/claude-opus-5"}

Import by id, then by path, same session:

$ paseo import 019fbb15-dd8f-7000-9922-4d962525d4e6 --provider omp --cwd /tmp/paseo-shim-test3 --json
{"agentId":"d16b5c35-...","status":"created","provider":"omp","cwd":"/tmp/paseo-shim-test3","title":"Reply with exactly OK"}

$ paseo ls
AGENT ID   NAME                   PROVIDER                                  THINKING  STATUS
d16b5c3    Reply with exactly OK  omp/anthropic/claude-3-5-sonnet-20240620  auto      idle     <- wrong

$ paseo import /Users/…/2026-08-01T02-10-00-207Z_019fbb15-dd8f-7000-9922-4d962525d4e6.jsonl \
    --provider omp --cwd /tmp/paseo-shim-test3 --json
{"agentId":"9d43e534-...","status":"created","provider":"omp","cwd":"/tmp/paseo-shim-test3","title":"Reply with exactly OK"}

$ paseo ls
AGENT ID   NAME                   PROVIDER                     THINKING  STATUS
9d43e53    Reply with exactly OK  omp/anthropic/claude-opus-5  high      idle     <- correct

The user-visible consequence, on an earlier import that landed on the default:

[System Error] 404 {"type":"error","error":{"type":"not_found_error","message":"model: claude-3-5-sonnet-20240620"}}
  (stopReason=error, model=anthropic/claude-3-5-sonnet-20240620)

The imported agent is unusable: the fallback model is not one this account can call, and nothing in the import output signals that the session config was dropped.

Expected behavior

paseo import <id> --provider omp produces an agent carrying the session's own model and thinking level, identical to importing by path.

Suggested fix

Resolve the handle to a session file before reading the descriptor. listOmpImportableSessions already walks the session directory and knows the id-to-path mapping, so importSession can reuse that resolution, or readOmpImportSessionConfig can accept either form and resolve an id itself. A silent {} on a failed descriptor read is also worth a warning log - it is indistinguishable from a session that genuinely records no model.

Where did this happen

CLI

Paseo version

0.2.5 (defect also present on main at the permalinks above)

OS version

macOS 26.5.0, arm64 (M4 Max)

Agent provider

omp (oh-my-pi), omp v17.2.2

[paseo-bot]

Keeping this open as a p2 bug. The report includes an exact reproduction on v0.2.5: importing the same OMP session by ID loses its model and thinking level, while importing by absolute path preserves both and avoids the fallback-model error.

Current main still accepts and forwards the CLI <id> unchanged, while the OMP import path passes that handle to its config reader and the reader opens the value as a file path. The absolute-path import is a workaround, so this is limited-impact but valid current work.