[Bug]: Project extension state can bypass `--trust` and execute repository-controlled runtime code

[glmgbj233]

Bug Description

Summary

Autohand Code CLI's project extension loader treats a repository-controlled .autohand/extensions/.state/<extension-id>.json file as the source of truth for runtime trust. A malicious repository can therefore commit a project extension, a JavaScript runtime entrypoint, and {"trusted":true} state. On a normal CLI launch, Autohand discovers the project extension and dynamically imports and activates the runtime before Commander parses the CLI arguments, before authentication, and before any model or tool interaction.

The documented extension workflow says executable runtime packages require an explicit --trust decision. That decision is not enforced by the automatic project loader: the loader does not verify who created the state file, whether it is user-owned state, whether the package content matches the trusted content, or whether the workspace is trusted. This is deterministic local process code execution from repository-controlled content, not prompt injection and not a model-dependent tool approval bypass.

I dynamically reproduced the behavior in isolated temporary checkouts from both upstream main@57b2fd50526bccc41c2b361eb7d76534a21aaf69 and stable v0.9.3@8595299fa7c2cb2f63715b03c48e39f26c6e2f7e. A marker-only runtime was activated by node_modules/.bin/tsx src/index.ts --help. The no-extension control and the same fixture with --bare did not create the marker.

Affected Revisions

• v0.9.3 (8595299fa7c2cb2f63715b03c48e39f26c6e2f7e)
• main (57b2fd50526bccc41c2b361eb7d76534a21aaf69)
• The project extension platform was introduced after the previously reviewed 2466944ddc7dd69a2644955bfc1887666cdf2386 revision.

Preconditions and Exact Trigger

The attacker must provide a repository containing the project extension files below. The victim must launch the Autohand CLI normally with that repository as the current directory or with --path. Merely opening the directory in a file manager or ordinary IDE is not the trigger unless that application separately launches Autohand for the workspace.

The smallest confirmed trigger is:

cd untrusted-repository
autohand --help

The same behavior occurs with autohand --version or autohand --path untrusted-repository. The command does not need a login, provider configuration, model request, prompt, or tool call. --bare skips this preparatory extension loader and is an explicit control, not the default launch mode.

Source-to-Sink Evidence

1. src/extensions/ExtensionRegistry.ts:132-154 reads the state path as path.join(path.dirname(installationPath), '.state', '<extension-id>.json') and sets trusted from parsed.data.trusted === true. For a project extension, this state path is inside the repository's .autohand/extensions tree.
2. src/extensions/ExtensionRegistry.ts:286-296 loads both user and project roots. src/extensions/ExtensionRegistry.ts:362-407 discovers package directories below the project root and skips .state only as a package candidate; it still consumes .state as trust metadata through readState.
3. src/index.ts:2588-2640 calls prepareRuntimeExtensionsForCli before program.parseAsync, derives the project root as <workspace>/.autohand/extensions, loads the registry, synchronizes the runtime host, and only then parses the CLI command.
4. src/extensions/ExtensionRuntimeHost.ts:447-498 filters for trusted runtime extensions and executes import(moduleUrl), then calls the exported activate(api) function. This is in-process JavaScript execution and does not pass through model tool authorization or shell approval.
5. The intended explicit trust gate is in src/extensions/ExtensionService.ts:189-192, where installation rejects runtime packages unless the caller supplies --trust. The automatic loader does not establish that the state file was produced by this install operation or that it is outside repository control.
6. src/extensions/ExtensionRuntimeHost.ts:388-400 computes its reload signature from runtime path, mtime, trust, and disabled state, not from a digest of the package and runtime contents. A trusted project state can therefore remain trusted across runtime content changes.

The extension documentation says runtime packages require --trust and that trusted runtime code has the same operating-system access as Autohand (docs/extensions.md:31-37,90-94; docs/extension-authoring.md:76-81). The implementation does not provide that trust boundary for project-controlled state.

Impact

Once activated, the repository-controlled runtime executes with the operating-system privileges and inherited environment of the Autohand process. Depending on the user's environment, it can read or modify accessible files, use user-writable persistence locations, access reachable network resources, or interact with locally available services. The issue does not require the attacker to persuade a model to call a tool.

The project .autohand/ directory is ignored by the upstream repository's own .gitignore, but Git ignore rules are not a security boundary. A different attacker-controlled repository can track these files, force-add them, or change its ignore rules. The CLI does not check Git tracked status before loading the project extension.

Why the Existing Test Does Not Cover This Case

tests/extensions/ExtensionService.test.ts:150-170 verifies that publisher-authored state inside an extension package is ignored and that installation state is stored outside that package. It does not verify that project-scope state is stored outside the repository, reject a committed project .state file, or bind trusted to a user-owned approval record and package digest.

Recommended Remediation

1. Never accept trusted:true from a project-controlled file as a user trust decision. Store runtime trust in user-owned application state keyed by canonical workspace identity and extension identity.
2. Default project runtime extensions to untrusted and require an explicit confirmation before activation. Declarative project contributions can remain separate from executable runtime contributions.
3. Bind approval to the canonical workspace, repository revision or equivalent provenance, extension id/version, and a digest of the complete extension package and referenced runtime files. Re-check the digest immediately before import() and invalidate approval on content or symlink-target changes.
4. Do not auto-import project runtime extensions during CLI bootstrap before the user has had an opportunity to review the resolved extension identity and runtime files.
5. Add regression tests covering a project extension with a committed .state/<id>.json containing trusted:true, a changed runtime after approval, and a symlink or package replacement. All must require a new user-owned trust decision or remain untrusted.

The existing .autohand/settings.local.json telemetry endpoint override and project permission-mode findings are related but separate trust-boundary issues and should be tracked independently from this executable project-extension finding.

Steps to Reproduce

Proof of Concept

Create these tracked-equivalent paths in a throwaway repository:

.autohand/extensions/evil.project/autohand.extension.json
.autohand/extensions/evil.project/runtime.mjs
.autohand/extensions/.state/evil.project.json

Use this manifest:

{
  "schemaVersion": 1,
  "extensionApi": 1,
  "id": "evil.project",
  "name": "Isolated Marker Fixture",
  "version": "1.0.0",
  "description": "Writes only an isolated marker",
  "contributes": { "runtime": ["runtime.mjs"] }
}

Use this state file:

{"trusted":true}

Use a marker-only runtime. It must write only to a temporary path supplied through AUTOHAND_MARKER and return a no-op deactivator:

import { writeFileSync } from 'node:fs';

export function activate() {
  writeFileSync(process.env.AUTOHAND_MARKER, JSON.stringify({ activated: true }));
  return () => {};
}

Run the CLI from the source checkout using the repository's supported TypeScript runner, with an isolated AUTOHAND_HOME and AUTOHAND_MARKER. The positive case creates the marker while printing help. Repeat with the project extension directory removed; the marker is not created. Repeat with the extension present and --bare; the marker is not created.

The reported dynamic run used npm install --ignore-scripts --no-audit --no-fund --package-lock=false only in temporary checkouts. The candidate test suite was not run. The application invocation did not contact an endpoint, read credentials, spawn a shell, or modify the source checkout.

Expected Behavior

I expected project runtime extensions to be treated as untrusted by default.

When Autohand starts in a workspace containing an executable project extension, it should display the extension identity and runtime entrypoints and require an explicit, user-owned trust decision before importing or activating the code. The approval should be invalidated when the extension content changes.

CLI startup modes such as autohand --help and autohand --version should not execute repository-controlled runtime code automatically.

Actual Behavior

Instead, Autohand automatically discovers project extensions under .autohand/extensions and reads the trust state from .autohand/extensions/.state/<extension-id>.json.

A repository-controlled state file containing {"trusted":true} is accepted as valid trust. Running autohand --help in the repository causes the runtime entrypoint to be imported and its activate() function to execute before CLI argument parsing, authentication, model interaction, or tool approval.

This was dynamically reproduced in stable v0.9.3 and upstream main. A marker-only runtime created the marker file. The no-extension control and --bare control did not create it.

Autohand Version

v0.9.3

Operating System

Linux (x64)

OS Version

No response

Installation Method

GitHub release binary

LLM Model (if applicable)

No response

Error Logs

Configuration (optional)

Checklist

• I have searched for existing issues that describe this bug
• I have removed any sensitive information (API keys, personal data) from the logs/config