Run config key 'assistants.pi.maxConcurrent' cannot apply: P

Error message

Run config key 'assistants.pi.maxConcurrent' cannot apply: Pi concurrency is initialized once for the process lifetime.

What it means

The 'pi' provider rejects the 'maxConcurrent' key in run config assistant defaults because Pi concurrency is initialized once for the process lifetime and cannot be changed per run. The config layer fails fast rather than letting a per-run value have no effect.

Source

Thrown at packages/core/src/config/run-config.ts:132

  }
}

/** Validate and normalize constraints owned by the live provider registry and lifecycle. */
export function normalizeRunConfigSemantics(layer: WorkflowRunConfigLayer): WorkflowRunConfigLayer {
  if (layer.assistant !== undefined) {
    assertRegisteredProvider(layer.assistant, 'assistant');
  }
  const assistants: Record<string, Record<string, unknown>> = {};
  for (const [provider, defaults] of Object.entries(layer.assistants ?? {})) {
    assertRegisteredProvider(provider, `assistants.${provider}`);
    if (provider === 'pi' && Object.hasOwn(defaults, 'env')) {
      throw new Error(
        "Run config key 'assistants.pi.env' cannot apply: Pi extension environment mutates " +
          'process.env and is process-scoped.'
      );
    }
    if (provider === 'pi' && Object.hasOwn(defaults, 'maxConcurrent')) {
      throw new Error(
        "Run config key 'assistants.pi.maxConcurrent' cannot apply: Pi concurrency is " +
          'initialized once for the process lifetime.'
      );
    }
    try {
      assistants[provider] = getRegistration(provider).parseRunConfig(defaults);
    } catch (error) {
      if (error instanceof InvalidProviderRunConfigError) {
        const suffix = error.fieldPath ? `.${error.fieldPath}` : '';
        throw new Error(
          `Invalid run config at 'assistants.${provider}${suffix}': ${error.message}.`
        );
      }
      throw error;
    }
  }
  const tiers = Object.fromEntries(
    Object.entries(layer.tiers ?? {}).map(([tier, preset]) => [

View on GitHub (pinned to 0773b97458)

Solutions

Remove 'maxConcurrent' from assistants.pi in the run config
Configure Pi concurrency once at process startup via its provider configuration
Use a provider that supports per-run concurrency if per-run tuning is required

Example fix

// before
assistants:
  pi:
    maxConcurrent: 4
// after
assistants:
  pi: {}  # set concurrency in pi provider startup config

Defensive patterns

Strategy: validation

Validate before calling

function assertPiAssistantDefaults(defaults) { if (defaults && ('maxConcurrent' in defaults)) throw new Error("assistants.pi.maxConcurrent is not supported; set concurrency at process startup"); }

Type guard

function hasPiMaxConcurrent(layer) { return typeof layer?.assistants?.pi === 'object' && layer.assistants.pi !== null && 'maxConcurrent' in layer.assistants.pi; }

Try / catch

try { cfg = parseWorkflowRunConfig(doc, source); } catch (e) { if (String(e.message).includes('assistants.pi.maxConcurrent')) { console.error('Configure pi concurrency once at process startup'); } throw e; }

Prevention

Set pi concurrency only in provider startup configuration
Strip process-scoped pi keys when generating per-workflow configs
Add a CI check rejecting maxConcurrent under assistants.pi

When it happens

Trigger: Calling runConfig(), parseWorkflowRunConfig(), or unsealWorkflowRunConfig() with assistants: { pi: { maxConcurrent: N } }.

Common situations: Porting a run config that sets maxConcurrent for other providers (e.g. claude, codex) over to pi; tuning parallelism per workflow and forgetting pi is process-wide.

Related errors

AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/2aee8fe8cbc49623. Report an issue: GitHub.