@engineeros/connector 0.26.0 → 0.27.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +115 -104
- package/bin/engineeros-connector.mjs +71 -70
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,33 +1,33 @@
|
|
|
1
|
-
# EngineerOS Connector
|
|
2
|
-
|
|
3
|
-
The connector uses an authenticated EngineerOS WebSocket for pairing, workspace identity, run lifecycle, and evidence. Coding work can run through any agent in the official ACP registry or a custom ACP v1-compatible command over stdio. Direct Codex CLI remains available as the compatibility path.
|
|
4
|
-
|
|
5
|
-
## Connect an official ACP agent
|
|
6
|
-
|
|
7
|
-
EngineerOS reads the curated [ACP agent registry](https://agentclientprotocol.com/registry), caches it for 24 hours, and uses the registry's pinned distribution for the current platform. The catalog includes Codex, Claude, Gemini, GitHub Copilot, Goose, OpenCode, Qwen Code, Cursor, and other compatible agents as they are published. List the current catalog, prepare the selected agent, then pair the workspace:
|
|
8
|
-
|
|
9
|
-
```sh
|
|
10
|
-
npx --yes @engineeros/connector@latest agents
|
|
11
|
-
npx --yes @engineeros/connector@latest agent gemini install
|
|
12
|
-
npx --yes @engineeros/connector@latest pair PAIRING-CODE --url https://your-engineeros.example --workspace . --onboard --agent gemini
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
Registry `npx` and `uvx` packages are prepared with their native package runner. Registry binaries are downloaded into `~/.engineeros/agents`, checked against the published SHA-256 digest when present, and launched from that managed location. The connector checks the selected distribution before pairing. Agent processes stay alive while the connector is active, project conversations reuse their ACP sessions, and response chunks reach Copilot as the agent produces them.
|
|
16
|
-
|
|
17
|
-
## Pair an ACP coding agent
|
|
18
|
-
|
|
19
|
-
Run the command from the repository the agent should work in:
|
|
20
|
-
|
|
21
|
-
```powershell
|
|
22
|
-
npx --yes @engineeros/connector@latest pair PAIRING-CODE --url http://localhost:8000 --workspace . --onboard --agent-name "My ACP agent" --agent-command my-agent --agent-args '["--acp"]'
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
`--agent-command` must start an ACP v1 agent over NDJSON stdio. `--agent-args` is a JSON array so arguments are passed without invoking a shell. Omit `--agent` and the custom command options to use the installed Codex CLI directly.
|
|
26
|
-
|
|
27
|
-
Connect a local Codex CLI workspace to EngineerOS through an outbound WebSocket.
|
|
28
|
-
|
|
29
|
-
## Agent roles and skills
|
|
30
|
-
|
|
1
|
+
# EngineerOS Connector
|
|
2
|
+
|
|
3
|
+
The connector uses an authenticated EngineerOS WebSocket for pairing, workspace identity, run lifecycle, and evidence. Coding work can run through any agent in the official ACP registry or a custom ACP v1-compatible command over stdio. Direct Codex CLI remains available as the compatibility path.
|
|
4
|
+
|
|
5
|
+
## Connect an official ACP agent
|
|
6
|
+
|
|
7
|
+
EngineerOS reads the curated [ACP agent registry](https://agentclientprotocol.com/registry), caches it for 24 hours, and uses the registry's pinned distribution for the current platform. The catalog includes Codex, Claude, Gemini, GitHub Copilot, Goose, OpenCode, Qwen Code, Cursor, and other compatible agents as they are published. List the current catalog, prepare the selected agent, then pair the workspace:
|
|
8
|
+
|
|
9
|
+
```sh
|
|
10
|
+
npx --yes @engineeros/connector@latest agents
|
|
11
|
+
npx --yes @engineeros/connector@latest agent gemini install
|
|
12
|
+
npx --yes @engineeros/connector@latest pair PAIRING-CODE --url https://your-engineeros.example --workspace . --onboard --agent gemini
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
Registry `npx` and `uvx` packages are prepared with their native package runner. Registry binaries are downloaded into `~/.engineeros/agents`, checked against the published SHA-256 digest when present, and launched from that managed location. The connector checks the selected distribution before pairing. Agent processes stay alive while the connector is active, project conversations reuse their ACP sessions, and response chunks reach Copilot as the agent produces them.
|
|
16
|
+
|
|
17
|
+
## Pair an ACP coding agent
|
|
18
|
+
|
|
19
|
+
Run the command from the repository the agent should work in:
|
|
20
|
+
|
|
21
|
+
```powershell
|
|
22
|
+
npx --yes @engineeros/connector@latest pair PAIRING-CODE --url http://localhost:8000 --workspace . --onboard --agent-name "My ACP agent" --agent-command my-agent --agent-args '["--acp"]'
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
`--agent-command` must start an ACP v1 agent over NDJSON stdio. `--agent-args` is a JSON array so arguments are passed without invoking a shell. Omit `--agent` and the custom command options to use the installed Codex CLI directly.
|
|
26
|
+
|
|
27
|
+
Connect a local Codex CLI workspace to EngineerOS through an outbound WebSocket.
|
|
28
|
+
|
|
29
|
+
## Agent roles and skills
|
|
30
|
+
|
|
31
31
|
The selected ACP or Codex agent is the execution engine. EngineerOS chooses a provider-neutral role for each activity and the connector injects exactly one bundled skill:
|
|
32
32
|
|
|
33
33
|
- `research` uses `project-research` to answer questions from observed project evidence.
|
|
@@ -37,25 +37,25 @@ The selected ACP or Codex agent is the execution engine. EngineerOS chooses a pr
|
|
|
37
37
|
- `verification` uses `independent-verification` with read-only access for artifact review and independent Goal proof.
|
|
38
38
|
|
|
39
39
|
This is intentionally a small executable catalog. Skills for hypothetical release, quality, or agent-workflow phases are not advertised until EngineerOS has a workflow that can invoke them. Harness-wide access, evidence, clarification, and output rules remain outside skill bodies, so an assignment pays only for the specialized judgment it needs. Direct Codex runs also disable ambient skill instructions; ACP providers receive the selected EngineerOS skill in the assignment prompt rather than the rest of the catalog.
|
|
40
|
-
|
|
41
|
-
The connector rejects a role whose access does not match the assignment before starting the agent. Role-specific sessions preserve useful context without mixing planning, research, implementation, or verification responsibilities. A shared interaction contract makes the Agent infer the current project situation, lead with the useful outcome, and suggest one concrete next activity only when it genuinely helps. User-visible responses refer neutrally to the Agent; provider and harness details remain operational metadata.
|
|
42
|
-
|
|
43
|
-
## Onboard a workspace
|
|
44
|
-
|
|
45
|
-
Create a connection command from **Project steering -> Connect workspace**, then run it inside the local folder:
|
|
46
|
-
|
|
47
|
-
```sh
|
|
48
|
-
npx --yes @engineeros/connector@latest pair PAIRING-CODE --url https://your-engineeros.example --workspace . --onboard
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
The connector uploads a bounded ZIP snapshot for a safe file inventory, then stays online for deep assessments, rescans, and Goal Runs. Inventory never executes repository code. It excludes known secrets, dependency directories, build output, compiled binaries, files larger than 5 MB, agent-tool caches, Git metadata, and connector state before upload.
|
|
52
|
-
|
|
53
|
-
From **Project steering -> Workspace**, run the workspace assessment to use the connected agent subscription already authenticated on that computer. Select any combination of fifteen brownfield assessment domains, collectively covering 133 internal checks from product and architecture through security, privacy, project-specific compliance, delivery, reliability, governance, and modernization planning. Reports include only material conclusions and actions; routine healthy checklist rows are not published. Capability entries state what they own, what they link to, and what they depend on. Connector `0.17.0` starts assessments with three parallel workers and accepts the run's UI-selected limit from three through eight for every coding-agent provider. It keeps one local assessment area at `.engineeros/assessment`: `assessment.md` is the canonical document, `sections/` holds the independently editable stage documents, `.work/` is the resumable transaction area, and an accepted update adds only a concise derived entry under `changes/`. A new run seeds each stage from its durable document, and a reconnect preserves any partially edited `.work` copy, so the coding agent updates affected content instead of regenerating the assessment. ACP agents such as OpenCode use isolated stage sessions within one persistent coding-agent process. The connector owns the worker pool and sends one aggregate heartbeat containing every active worker's phase, progress, last activity, and event count; report content is no longer streamed over the WebSocket or written into backend assessment JSON. The backend validates stage checkpoints so dependency fan-out remains authoritative, while the connector retains completed reports and reloads interrupted ACP or Codex sessions after reconnect when the coding agent supports session restoration. Transient ACP, app-server, provider-availability, and rate-limit failures receive two bounded attempts to continue the saved session without repeating completed inspection. A changed Git commit edits the same durable assessment, retains the prior commit in assessment history, and updates published artifacts in place. Connector reports and session checkpoints are tagged with their target commit so an earlier revision cannot leak into the update. If no assessment exists, EngineerOS creates the initial assessment identity and documents. Capability detail and project-specific compliance controls fan out after their catalogs. Final synthesis reads the connector-local Markdown files, then one completed bundle is revalidated, persisted, published as canonical artifacts, and archived locally. Compliance findings describe repository-verifiable engineering readiness and missing external context, never legal compliance or certification. The connector prints each worker's safe activity and elapsed time every 30 seconds, stops a worker that produces no agent activity for ten minutes instead of waiting indefinitely, and asks the same agent session to repair the same document when structure or backend validation fails. Assessment cannot modify tracked workspace source outside its assigned document.
|
|
54
|
-
|
|
55
|
-
Every backend `422` content-validation response is returned to the stage agent with the exact failed item. Distinct validation failures continue through correction and resubmission until the complete stage is accepted. Three repetitions of the same unresolved validation error stop the automatic loop while preserving the latest local report for retry. Authentication, cancellation, source drift, and transport failures remain operational errors rather than agent-correction prompts.
|
|
56
|
-
|
|
57
|
-
Assessment runs start by reporting whether an accepted assessment exists and how stale it is. Every assigned stage still runs against the current repository revision; durable reports do not contain a trustworthy dependency manifest, so the connector never presents an old section as newly inspected. Connector-owned files under `.engineeros` are ignored before drafts or context packs are created and therefore do not pollute repository change scans.
|
|
58
|
-
|
|
40
|
+
|
|
41
|
+
The connector rejects a role whose access does not match the assignment before starting the agent. Role-specific sessions preserve useful context without mixing planning, research, implementation, or verification responsibilities. A shared interaction contract makes the Agent infer the current project situation, lead with the useful outcome, and suggest one concrete next activity only when it genuinely helps. User-visible responses refer neutrally to the Agent; provider and harness details remain operational metadata.
|
|
42
|
+
|
|
43
|
+
## Onboard a workspace
|
|
44
|
+
|
|
45
|
+
Create a connection command from **Project steering -> Connect workspace**, then run it inside the local folder:
|
|
46
|
+
|
|
47
|
+
```sh
|
|
48
|
+
npx --yes @engineeros/connector@latest pair PAIRING-CODE --url https://your-engineeros.example --workspace . --onboard
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
The connector uploads a bounded ZIP snapshot for a safe file inventory, then stays online for deep assessments, rescans, and Goal Runs. Inventory never executes repository code. It excludes known secrets, dependency directories, build output, compiled binaries, files larger than 5 MB, agent-tool caches, Git metadata, and connector state before upload.
|
|
52
|
+
|
|
53
|
+
From **Project steering -> Workspace**, run the workspace assessment to use the connected agent subscription already authenticated on that computer. Select any combination of fifteen brownfield assessment domains, collectively covering 133 internal checks from product and architecture through security, privacy, project-specific compliance, delivery, reliability, governance, and modernization planning. Reports include only material conclusions and actions; routine healthy checklist rows are not published. Capability entries state what they own, what they link to, and what they depend on. Connector `0.17.0` starts assessments with three parallel workers and accepts the run's UI-selected limit from three through eight for every coding-agent provider. It keeps one local assessment area at `.engineeros/assessment`: `assessment.md` is the canonical document, `sections/` holds the independently editable stage documents, `.work/` is the resumable transaction area, and an accepted update adds only a concise derived entry under `changes/`. A new run seeds each stage from its durable document, and a reconnect preserves any partially edited `.work` copy, so the coding agent updates affected content instead of regenerating the assessment. ACP agents such as OpenCode use isolated stage sessions within one persistent coding-agent process. The connector owns the worker pool and sends one aggregate heartbeat containing every active worker's phase, progress, last activity, and event count; report content is no longer streamed over the WebSocket or written into backend assessment JSON. The backend validates stage checkpoints so dependency fan-out remains authoritative, while the connector retains completed reports and reloads interrupted ACP or Codex sessions after reconnect when the coding agent supports session restoration. Transient ACP, app-server, provider-availability, and rate-limit failures receive two bounded attempts to continue the saved session without repeating completed inspection. A changed Git commit edits the same durable assessment, retains the prior commit in assessment history, and updates published artifacts in place. Connector reports and session checkpoints are tagged with their target commit so an earlier revision cannot leak into the update. If no assessment exists, EngineerOS creates the initial assessment identity and documents. Capability detail and project-specific compliance controls fan out after their catalogs. Final synthesis reads the connector-local Markdown files, then one completed bundle is revalidated, persisted, published as canonical artifacts, and archived locally. Compliance findings describe repository-verifiable engineering readiness and missing external context, never legal compliance or certification. The connector prints each worker's safe activity and elapsed time every 30 seconds, stops a worker that produces no agent activity for ten minutes instead of waiting indefinitely, and asks the same agent session to repair the same document when structure or backend validation fails. Assessment cannot modify tracked workspace source outside its assigned document.
|
|
54
|
+
|
|
55
|
+
Every backend `422` content-validation response is returned to the stage agent with the exact failed item. Distinct validation failures continue through correction and resubmission until the complete stage is accepted. Three repetitions of the same unresolved validation error stop the automatic loop while preserving the latest local report for retry. Authentication, cancellation, source drift, and transport failures remain operational errors rather than agent-correction prompts.
|
|
56
|
+
|
|
57
|
+
Assessment runs start by reporting whether an accepted assessment exists and how stale it is. Every assigned stage still runs against the current repository revision; durable reports do not contain a trustworthy dependency manifest, so the connector never presents an old section as newly inspected. Connector-owned files under `.engineeros` are ignored before drafts or context packs are created and therefore do not pollute repository change scans.
|
|
58
|
+
|
|
59
59
|
After onboarding, every project prompt is routed to this connection. Copilot, shaping, planning, architecture, and experience generation use the connected agent subscription and workspace context. Interactive prompts run independently from assessments and Goal scheduling. Prompt runs are read-only; only an explicitly registered Goal Run receives workspace-write access. If the connector is offline, EngineerOS asks the user to reconnect instead of silently switching models.
|
|
60
60
|
|
|
61
61
|
Greenfield prompts also receive a bounded project-evidence manifest. EngineerOS normalizes uploaded text,
|
|
@@ -79,59 +79,70 @@ stores its files under `.engineeros/design/01-discovery` through `.engineeros/de
|
|
|
79
79
|
a manifest and remains directly editable by a human. Later stages read the approved earlier directories as their
|
|
80
80
|
authoritative inputs. The planning Agent remains read-only: the connector, not the Agent process, owns the bounded
|
|
81
81
|
local write, and an existing stage directory must be deleted explicitly before regeneration.
|
|
82
|
-
|
|
83
|
-
Project prompts use resumable, role- and purpose-specific agent sessions. The connector keeps the external session identifiers in its local configuration, so Copilot and artifact conversations survive connector restarts. Changing the role, purpose, model, or reasoning effort starts a separate session. Goal implementation and verification remain isolated runs.
|
|
84
|
-
|
|
85
|
-
An empty or document-only folder establishes a greenfield baseline. A code-bearing folder is assessed as brownfield. Use **Rescan** in Steering after the local workspace changes.
|
|
86
|
-
|
|
87
|
-
## Reconnect
|
|
88
|
-
|
|
89
|
-
```sh
|
|
90
|
-
npx --yes @engineeros/connector@latest start --workspace .
|
|
91
|
-
```
|
|
92
|
-
|
|
93
|
-
Credentials are stored per workspace under `~/.engineeros/connectors` with owner-only permissions where supported.
|
|
94
|
-
If a new pairing command is accidentally run from the same folder against the same EngineerOS server, the connector reuses this saved identity instead of creating another baseline assessment.
|
|
95
|
-
|
|
96
|
-
## Run Goals
|
|
97
|
-
|
|
98
|
-
Keep the connector online to receive Goals assigned from EngineerOS. Each
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
npx @engineeros/connector start --workspace .
|
|
82
|
+
|
|
83
|
+
Project prompts use resumable, role- and purpose-specific agent sessions. The connector keeps the external session identifiers in its local configuration, so Copilot and artifact conversations survive connector restarts. Changing the role, purpose, model, or reasoning effort starts a separate session. Goal implementation and verification remain isolated runs.
|
|
84
|
+
|
|
85
|
+
An empty or document-only folder establishes a greenfield baseline. A code-bearing folder is assessed as brownfield. Use **Rescan** in Steering after the local workspace changes.
|
|
86
|
+
|
|
87
|
+
## Reconnect
|
|
88
|
+
|
|
89
|
+
```sh
|
|
90
|
+
npx --yes @engineeros/connector@latest start --workspace .
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
Credentials are stored per workspace under `~/.engineeros/connectors` with owner-only permissions where supported.
|
|
94
|
+
If a new pairing command is accidentally run from the same folder against the same EngineerOS server, the connector reuses this saved identity instead of creating another baseline assessment.
|
|
95
|
+
|
|
96
|
+
## Run Goals
|
|
97
|
+
|
|
98
|
+
Keep the connector online to receive Goals assigned from EngineerOS. Each run explicitly selects one workspace
|
|
99
|
+
mode. `local_branch` creates or reuses `engineeros/goal-<goal-id>` in the connected repository, runs with its exact
|
|
100
|
+
local dependencies and properties, and returns to the original branch after a clean committed run. It is the
|
|
101
|
+
default for a dedicated agent machine and fails without stashing when another branch has uncommitted work.
|
|
102
|
+
`isolated_worktree` creates one durable worktree at `<repository-parent>/.engineeros/goals/<goal-id>` and reuses it
|
|
103
|
+
across retries. The worktree shares Git configuration and hooks and copies individual ignored local configuration
|
|
104
|
+
files; ignored dependency and build directories are not duplicated. The coding-agent process inherits the
|
|
105
|
+
connector environment in both modes. Cancellation stops the agent. The connector returns changed paths, a bounded
|
|
106
|
+
diff, and the exact repository ZIP; a human still performs independent attestation. Accepted work fast-forwards
|
|
107
|
+
into an unchanged clean connected branch, or cherry-picks the complete Goal commit range onto a clean branch that
|
|
108
|
+
advanced, then refreshes the workspace snapshot. Dirty or conflicting workspaces are never overwritten: the Goal
|
|
109
|
+
branch remains available for explicit review and merge.
|
|
110
|
+
|
|
111
|
+
During the writable implementation phase, Codex receives an authenticated EngineerOS MCP server automatically. It can list, read, create, update, reclassify, soft-delete, and materialize project artifacts into canonical Product records through the same repository boundary used by Copilot. The backend accepts those calls only while the assigned Goal is running. Read-only project prompts and the independent verification phase do not receive mutation tools.
|
|
112
|
+
|
|
113
|
+
## Local context engine
|
|
114
|
+
|
|
115
|
+
The connector keeps a local index for each workspace under `~/.engineeros/context/<connector id>/workspaces/`: file classifications, symbols, document headings, and import relationships for every safe file. Separating indexes by resolved workspace keeps the source checkout and concurrent Goal worktrees from replacing one another. An index is built at onboarding, refreshed incrementally from file digests when EngineerOS triggers a workspace refresh, and re-checked before every assignment.
|
|
116
|
+
|
|
117
|
+
Every assignment prompt arrives with a bounded, task-ranked Markdown working set. It names the most relevant paths, symbol and heading locations, local dependencies, direct consumers, and candidate tests, followed by a pointer to the durable source map at `.engineeros/context/source-map.md`. The connector ranks from the assignment's focused context query, frozen Goal packet, assessment stage identity, or current project request as appropriate. It never pastes source-file contents into the prompt; the Agent reads deeper through the source map, the listed files, assessment sections, ordinary file tools, or the attached `engineeros_*` MCP tools. Ranking is structural and lexical, using indexed paths, symbols, summaries, and imports; it does not generate or store embeddings.
|
|
118
|
+
|
|
119
|
+
Context preparation is a launch prerequisite for every role. The connector refreshes the correct workspace index, verifies that the source map exists, and stops before starting an agent with an actionable error when pairing identity, indexing, or map generation is unavailable. Resumed project sessions also receive a bounded `Session Memory` digest of relevant earlier turns in the same session, kept under `~/.engineeros/context/<connector id>/sessions/`, so follow-up prompts build on prior conclusions instead of re-deriving them. Entries carry a derived kind (fix, decision, change, or conclusion), and cross-session recall is stamped with its source session and last-active time.
|
|
120
|
+
|
|
121
|
+
Every direct Codex assignment — project prompt, assessment, Goal implementation, and independent verification — receives the local read-only context MCP server with `engineeros_search`, `engineeros_outline`, `engineeros_read_symbol`, `engineeros_similar`, `engineeros_blast_radius`, and `engineeros_recall`. Registry-backed ACP adapters receive the same runtime-workspace server through `session/new` and `session/load`. Only a writable Goal implementation receives the authenticated EngineerOS artifact MCP server; project prompts, assessments, and verification never receive mutation tools. Custom ACP commands receive no injected servers because they have no registry MCP contract.
|
|
122
|
+
|
|
123
|
+
After Goal implementation commits its isolated worktree change, the connector rebuilds context from that exact post-commit workspace before starting the independent verifier. Verification therefore receives the current task-ranked working set plus a bounded `Change Impact` section naming changed files, direct importers, and candidate tests rather than relying on the pre-change index. `engineeros_similar` helps the Agent extend existing functions, classes, and types instead of duplicating them. Stored symbol outlines omit literal constant values, MCP search responses are capped at one hundred files, and the index, source map, prompt context, and session memory remain on the local computer.
|
|
124
|
+
|
|
125
|
+
## Requirements
|
|
126
|
+
|
|
127
|
+
Node.js 22 or newer, Git, and an authenticated agent. `npx` distributions use npm, `uvx` distributions require uv, and binary archives require `tar` (`unzip` for ZIP files on Linux). Registry agents report their own authentication prerequisites when they start.
|
|
128
|
+
|
|
129
|
+
## Execution profiles
|
|
130
|
+
|
|
131
|
+
EngineerOS can set a workspace default model and reasoning effort, then override either value for an individual Goal. The same workspace default is used for assessments, Copilot, and generated artifacts. The connector passes the resolved values to Codex CLI and reports unsupported profiles instead of silently ignoring them.
|
|
132
|
+
|
|
133
|
+
Codex connectors advertise `gpt-5.6-sol` and `gpt-5.6-terra` by default. Override the choices shown in EngineerOS before starting the connector:
|
|
134
|
+
|
|
135
|
+
```sh
|
|
136
|
+
ENGINEEROS_AGENT_MODELS="model-a,model-b" npx @engineeros/connector start --workspace .
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
## Codex CLI compatibility
|
|
140
|
+
|
|
141
|
+
The connector prints the exact Codex CLI version it will use before connecting. If the
|
|
142
|
+
configured model requires a newer CLI, update Codex and restart the connector:
|
|
143
|
+
|
|
144
|
+
```sh
|
|
145
|
+
npm install -g @openai/codex@latest
|
|
146
|
+
codex --version
|
|
147
|
+
npx @engineeros/connector start --workspace .
|
|
137
148
|
```
|