Security is disabled; enable security.enabled before startin

Error message

Security is disabled; enable security.enabled before starting a scan

What it means

start() re-checks security.enabled before executing a scan (independent of the preflight check). Even with a valid plan id, launching a scan is refused while the feature flag is off, because execution spawns sessions, worktrees, and model calls.

Source

Thrown at packages/coding-agent/src/security/coordinator.ts:462

				target: input.target ?? { kind: "repository" },
				knowledgeBasePaths: input.knowledgeBasePaths,
				outputRoot: input.outputRoot ?? path.join(workRoot, Bun.randomUUIDv7()),
				archiveExisting: input.archiveExisting,
				model: modelRef,
				account,
				config: securityConfigSnapshot(this.#host.settings),
				workflowFingerprint: SECURITY_WORKFLOW_FINGERPRINT,
				signal: input.signal,
			},
			this.#gitAdapter,
		);
		await store.putPlan(plan);
		return plan;
	}

	async start(input: SecurityStartInput): Promise<SecurityOperationSnapshot> {
		if (!this.#host.settings.get("security.enabled")) {
			throw new Error("Security is disabled; enable security.enabled before starting a scan");
		}
		await this.#ensureRecovered();
		const store = await this.#openStore(this.#host.cwd);
		const plan = await store.getPlan(input.planId);
		if (!plan) throw new Error(`Unknown security scan plan: ${input.planId}`);
		await assertSecurityScanPlanFresh(
			plan,
			{
				config: securityConfigSnapshot(this.#host.settings),
				workflowFingerprint: SECURITY_WORKFLOW_FINGERPRINT,
			},
			this.#gitAdapter,
		);
		const operationId = this.#createOperationId();
		const scanId = createSecurityScanId();
		const createdAt = toIsoTimestamp(this.#now);
		const snapshot: SecurityOperationSnapshot = {
			operationId,

View on GitHub (pinned to 9690622007)

Solutions

Enable security.enabled in the settings visible to the process calling start(), then retry.
Re-plan (preflight) in the same environment where you intend to start, so flag state and plan are consistent.
If the flag is toggled at runtime, verify with settings.get("security.enabled") before invoking start().

Example fix

// before
if (!settings.get("security.enabled")) settings.set("security.enabled", true);
await coordinator.start({ planId });
// after
await coordinator.start({ planId }); // with security.enabled: true in config

Defensive patterns

Strategy: validation

Validate before calling

if (!settings.get("security.enabled")) throw new Error("enable security.enabled before starting a scan");

Try / catch

try {
  await coordinator.start(input);
} catch (err) {
  if (err instanceof Error && err.message.startsWith("Security is disabled")) {
    // enable the flag or abort the workflow; plan state remains valid
  } else throw err;
}

Prevention

Re-check the flag in the same process/config scope that will run start(), not just at preflight.
Avoid toggling security.enabled between planning and execution.
Run plan+start within one environment so settings snapshots agree.

When it happens

Trigger: Calling start() with any SecurityStartInput while settings.get("security.enabled") is false — e.g. the flag was disabled after preflight produced a plan, or start() is invoked in a process/session with different (disabled) settings than the one that planned the scan.

Common situations: Config reloaded between planning and start; scanning from a different project directory where security.enabled is not enabled; automation that reuses a persisted plan id across environments.

Related errors

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