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. When a known read result is much larger than the few facts needed, a deterministic result view can select those values or counts before the full inventory enters the Agent context. Full responses remain the default for exploration.

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.0a17 carries the same bounded result views through durable waits and read-only plan steps, while rejecting result projection on mutations before any change begins. 0.1.0a16 adds deterministic bounded views for known large read results, preserving the normal Run evidence while sending only selected values, counts, or existence facts into Agent context. It also makes audit analysis use complete Runtime-observed calls instead of raw event windows. 0.1.0a15 makes routine audit retrieval compact while retaining explicit forensic expansion, and hardens bounded Windows transport shutdown when taskkill cannot finish the descendant tree. 0.1.0a14 kept generated Codex profiles narrow when several cached releases expose the same Skill: one canonical source is enabled and retained older copies are explicitly disabled. 0.1.0a13 added one-call validated execution plans for short deterministic EDA sequences. Runtime prevalidates target-specific capabilities and unique mutation identities before the first change, waits for durable dependencies internally, stops on failure, and retains each step's purpose, Run, timing, and audit link. Codex and Pi expose the same operation; single operations still use the smaller direct tools. 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. Audit retrieval is context-bounded: audit analyze returns aggregate waste signals, audit list returns compact call rows, and only explicit audit list --full expands forensic events.

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.0a17"
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.