Trusted extension must be an existing module file: ${trusted

Error message

Trusted extension must be an existing module file: ${trustedPath}

What it means

loadTrustedSessionExtensions validates each explicitly trusted extension path before loading. If statSync fails — the path does not exist or is inaccessible — it throws this error, because a trusted extension is loaded with full privileges and must point at a real module file.

Source

Thrown at packages/coding-agent/src/main.ts:395

	authStorage: AuthStorage;
	modelRegistry: ModelRegistry;
	parsedArgs: Pick<Args, "apiKey" | "trustedExtensions" | "tools">;
	rawArgs: string[];
	createSession: (options: CreateAgentSessionOptions) => Promise<CreateAgentSessionResult>;
}

async function loadTrustedSessionExtensions(
	options: Pick<CreateAgentSessionOptions, "additionalExtensionPaths">,
	cwd: string,
	eventBus: EventBus,
) {
	const paths = options.additionalExtensionPaths ?? [];
	for (const trustedPath of paths) {
		let stat: fsSync.Stats;
		try {
			stat = fsSync.statSync(trustedPath);
		} catch {
			throw new Error(`Trusted extension must be an existing module file: ${trustedPath}`);
		}
		if (!stat.isFile()) {
			throw new Error(`Trusted extension must be a module file, not a directory: ${trustedPath}`);
		}
	}
	return loadExtensions(paths, cwd, eventBus);
}

/**
 * Build the per-`session/new` factory used by ACP mode.
 *
 * MCP servers in ACP sessions are owned exclusively by the ACP client, which
 * supplies them through `session/new.mcpServers` and re-applies them via
 * {@link AcpAgent#configureMcpServers}. We therefore force `enableMCP: false`
 * on every session created here so {@link createAgentSession} skips the on-disk
 * `.mcp.json` discovery path — otherwise host MCP tools land in the session's
 * tool registry and shadow the client-supplied servers (issue #1234).
 */

View on GitHub (pinned to 9690622007)

Solutions

Correct the configured path in your omp config / CLI flag so it points at the existing extension module file.
Delete or comment out the stale trusted-extension entry if the extension is no longer needed.
Verify the path with `ls -l <path>` and that the target is a regular file (directories raise the sibling 'not a directory' error).
Reinstall or rebuild the extension if it was removed by a clean/rebuild.

Example fix

// before
omp --extension /home/me/extensions/my-ext.ts  // file deleted
// after
bun build extensions/my-ext.ts --outfile ~/.omp/extensions/my-ext.js
omp --extension ~/.omp/extensions/my-ext.js

Defensive patterns

Strategy: validation

Validate before calling

import * as fsSync from "node:fs";
function trustedExtensionPathsOk(paths: string[]) {
  return paths.filter(p => { try { return fsSync.statSync(p).isFile(); } catch { return false; } });
}

Type guard

function isModuleFile(p: string): p is string {
  try { return fsSync.statSync(p).isFile(); } catch { return false; }
}

Try / catch

try {
  await startSession({ additionalExtensionPaths });
} catch (err) {
  if (err instanceof Error && err.message.startsWith("Trusted extension must be")) {
    const missing = err.message.split(": ")[1];
    console.error(`Fix or remove trusted extension path: ${missing}`);
    return startSession({ additionalExtensionPaths: paths.filter(p => p !== missing) });
  } throw err;
}

Prevention

Validate extension paths at config-load time and warn instead of failing at startup.
Use paths relative to a stable config dir, and re-resolve symlinks after rebuilds.
Keep extension files out of clean/build wipe targets, or reinstall them in a postinstall hook.

When it happens

Trigger: Starting omp with additionalExtensionPaths (trusted extensions) containing a path that does not exist, has a typo, or is not readable — raised in loadTrustedSessionExtensions during startup extension resolution.

Common situations: Config drift after moving/deleting an extension file; absolute paths baked into config on another machine; wrong casing or extension (.js vs .ts) in the configured path; symlinks pointing at removed targets.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/bc497f78b2b26765. Report an issue: GitHub.