EDA Bridge Runtime

Keep EDA work reliable whether the Agent runs beside the tool or reaches it over SSH.

eda-bridge-runtime is an agent-neutral execution layer for EDA automation. It gives local and SSH-driven bridges the same request envelope, durable job semantics, context handoff, timing evidence, and append-only execution ledger.

The runtime is intentionally not an EDA bridge and not an AI harness. Vendor bridges keep their native API knowledge. Agents state a short purpose; the runtime records what was requested, what actually ran, how long each phase took, and what result or artifact was produced.

What changes for the user

You state the task and intended target once. The Runtime carries the same request through a local or remote path, keeps long work recoverable across a disconnect, and returns the result with its linked timing and evidence.

Design promises

• Local and SSH execution use one protocol and one evidence model.
• Every agent-originated operation carries a concise purpose.
• Actor metadata is collected automatically where possible and records its provenance; missing metadata never blocks engineering work.
• Mutating requests are idempotent and auditable.
• Disconnection does not imply that a long EDA job failed.
• Context tokens contain locators and fingerprints, never credentials.
• EDA-specific behavior lives in adapters, not in the runtime core.

Current alpha

0.1.0a8 keeps the Runtime as the stable fact recorder and adds capability-aware read/write classification plus one-call durable-job waiting. Every MCP client contributes its observed client identity, concise purpose, argument fingerprint, timings, and linked Run without depending on a Codex- or Pi-specific hook. Agent hooks may add richer model/session metadata, but they are optional enrichment. Agent adapters may attach bounded provider, model, reasoning, session, and tool-call metadata; Runtime labels these values declared, while MCP client identity remains independently observed. A bounded eda.connection.reset action closes only a stale Runtime-owned transport after an upgrade; it never closes or modifies the EDA application.

0.1.0a5 added optional Codex lifecycle enrichment for session, turn, model, permission mode, and tool-call identity. The append-only audit stores neither raw operation payloads nor chat transcripts.

0.1.0a4 adds rich bounded Context snapshots, stable origin routing, direct one-submit execution, and automatic origin binding during connection setup. Vendor Skills can declare the Runtime MCP directly, so users select one task-facing Skill rather than manually composing infrastructure Skills.

python -m pip install "eda-bridge-runtime==0.1.0a8"
eda-runtime doctor

For repository development, create a virtual environment and install .[dev] instead. Public releases are built once on a clean GitHub runner, published through PyPI Trusted Publishing, and installed back from PyPI before acceptance.

See Architecture and the protocol schema. Host placement is defined by the agent-client, eda-worker, and combined deployment roles.

The lightweight Pi Agent pilot and its checked-in thin adapter are described in Pi Agent pilot. They reuse the same Runtime boundary instead of adding a second SSH or EDA-control path.

The repository also includes a minimal MCP and Codex plugin. It resolves named local/SSH connections without asking the agent to assemble transport commands on each call. Sanitized real-host evidence is recorded in acceptance results.