[not502]

Add @magpie-community/agent-trae 0.2.0

Trae (ByteDance's AI IDE) as a Magpie agent, with a visible preview/confirm step before anything is written to Trae's cloud.

Changes since the review

• Own sign-in only: removed trae-crypto.mjs and every read of Trae's credential store. The only credential source is the package's own trae-agent browser sign-in (magpie plugin login trae-agent), stored by Magpie under trae-agent in plugin-auth.json.
• Per-agent key only: removed gatewayKey() and all reads of caller-keys.json / settings.json gateway keys. The gateway model list is read with the per-agent key Magpie writes into connection.json.
• Visible confirmation: no model sync on connect and none in the bridge's polling loop. The plugin page Trae models shows what would be added, removed and kept; Mirror to Trae… asks for confirmation and only then writes. The state file is written only after a confirmed mirror.
• MCP mirror unchanged: local User/mcp.json, only entries the plugin wrote.

Hosts the runtime can reach

Trae model API (the account token is sent only to these):

• https://coresg-normal.trae.ai
• https://core-normal.trae.ai
• https://coreva-normal.trae.ai
• https://core-normal.traeapi.us
• https://core-normal.trae.cn
• the host saved in ~/.trae/magpie/trae-host.json (normally one of the above)

Sign-in renewal:

• https://growsg-normal.trae.ai
• https://grow-normal.trae.cn

Other:

• the Magpie gateway origin from connection.json (default http://127.0.0.1:3425; the per-agent key is used there, never the Trae account token);
• https://www.trae.ai/authorization is opened in the browser by Magpie for sign-in; the plugin's runtime does not fetch it.

No other network hosts are reachable by the code.

Trae CN sign-in

Only trae-agent's own entry is read or refreshed. The plugin never reads trae-global or trae-cn; the existing Trae CN subscription's saved sign-in is untouched.

Testing

• bun test packages/agent-trae → 32 pass.
• bun scripts/check.mjs → passes.
• In real Magpie on Windows: connecting the row leaves model-state.json untouched; the page preview listed the add/remove changes; confirming through the page added and later removed a model; no Trae window or extension involved.

[yetone]

Thanks, @not502. Before a line-by-line review, this needs the maintainer to look first. It handles credentials: there's a browser sign-in of its own, trae-auth.mjs with trae-crypto.mjs, and it reads Trae's local sign-in. It also talks to Trae's own hosts (core-normal.trae.ai, .trae.cn, coresg-normal, grow-normal…). Our review rule is to hold a PR like that until the maintainer has looked, so nothing has been run or merged yet.

Two questions you can answer in the meantime:

• Does the runtime ever send the Trae account's token anywhere other than Trae's own hosts? Answer with the exact list of hosts the code can reach.
• magpie already has a Trae CN subscription. Does a Trae account signed in here touch that subscription's saved sign-in, or only trae-agent's own?

[yetone]

Holding this one; it can't merge as it stands. Reviewed at 42f1fe5.

1. It sends a magpie key to Trae's cloud without asking. gatewayKey() reads magpie's own caller-keys.json and picks the key marked lan: true first (so the key that opens the gateway to the network), else the first key. connect then saves it with the model rows in Trae's cloud model store. The README calls this "静默镜像". A key that reaches magpie from other machines then sits on a third party's servers, and the user never saw a step that sent it. A plugin uses the key magpie hands it for this agent. It never reads caller-keys.json, and it never uploads anything without a step the user confirms.
2. It decrypts Trae's credential store. trae-crypto.mjs reimplements Trae's byteCrypto to read the account token out of storage.json, and trae-auth.mjs mints its own device key pair. The plugin already has its own sign-in flow; use only that, so nothing reads another app's encrypted secrets.
3. It does it on every start. Writing to the account's cloud model list on every start, with no visible step, is a lot to do on someone's account. Mirror the models only when the user asks, and show which models were added.

With those changes (its own sign-in only, the per-agent key, a visible confirm before anything goes to Trae's cloud), I'll review it again.

[yetone]

Correction to point 3: the mirror runs from connect, when the Trae row is connected in magpie, not on every start. What still applies is that connecting uploads the key with no step that says it will. Points 1 and 2 stand.

[not502]

Thanks for the review. All three points are addressed in 0.2.0, and I answered the two questions below.

1. Caller-keys / per-agent key: gatewayKey() and every read of caller-keys.json / settings.json gateway keys are gone. GET /v1/models uses only the per-agent key from connection.json. The mirror reuses the encrypted model key already stored in Trae; it never uploads a new key.
2. Trae credential store: trae-crypto.mjs is deleted. The only sign-in is the package's own trae-agent browser flow; nothing reads storage.json or another app's secrets.
3. No silent upload: the bridge no longer mirrors models on connect or in its polling loop. The page Trae models previews add/remove/keep, and Mirror to Trae… requires an explicit confirmation. model-state.json is written only after that confirmed mirror.

Hosts the runtime can reach (the Trae account token is sent only to the Trae model API):

• https://coresg-normal.trae.ai
• https://core-normal.trae.ai
• https://coreva-normal.trae.ai
• https://core-normal.traeapi.us
• https://core-normal.trae.cn
• the saved host in ~/.trae/magpie/trae-host.json (normally one of the above)

Sign-in renewal: https://growsg-normal.trae.ai, https://grow-normal.trae.cn.
Other: the Magpie gateway origin from connection.json (the per-agent key is used there, never the Trae account token); https://www.trae.ai/authorization is opened in the browser by Magpie, not fetched by the runtime.

Trae CN: only trae-agent's own entry is read/refreshed. trae-global and trae-cn are never read, and the Trae CN subscription's saved sign-in is untouched.

Tests: 32 pass; bun scripts/check.mjs passes; in real Magpie, connecting leaves model-state.json untouched and the page's confirmed mirror added/removed the expected model.

[yetone]

Re-checked at 5766c3e. All three points I raised are fixed:

1. Nothing reads caller-keys.json or settings.json any more. The per-agent key from connection.json is sent only to the local gateway's /v1/models (bridge.mjs). Trae's cloud gets the plugin's own Cloud-IDE-JWT and a hash of the key in local model-state.json, never the key itself.
2. trae-crypto.mjs is gone and nothing reads storage.json. Sign-in is the package's own loopback OAuth against www.trae.ai/authorization.
3. applyMirror refuses to run without confirm: true and a fresh preview id, and the page shows the add/remove count before it writes.

My hold for possible harm is lifted. The rest of the review can go ahead as usual.

[not502]

Thanks for lifting the hold. The pr workflow for 5766c3e is still showing action_required (first-time contributor approval), so its tests/check haven't run yet. Could a maintainer approve the workflow run when convenient?

Locally the package passes bun test (32 tests) and bun scripts/check.mjs; the page preview/confirm flow was also exercised against a real Magpie install.

[yetone]

@not502 I ran 5766c3e on Linux (Bun 1.4.2, temp HOME): 31 pass, 1 fail. bun scripts/check.mjs agent-trae is ok.

(fail) pathsFor follows the three platforms
test/bridge.test.mjs:61
+ 'C:\\Users\\ada\\AppData\\Roaming\\Trae\\User\\mcp.json'
- 'C:\\Users\\ada\\AppData\\Roaming/Trae/User/mcp.json'

The code is right, and the test is what's wrong. pathsFor builds the Windows path with Windows separators, but the test's expected value uses join from node:path, which follows the machine the test runs on. So it passes only on Windows, and the ubuntu and macOS jobs in CI would fail the same way. Building the win32 expectation with path.win32.join (and the posix ones with path.posix.join) fixes it.

I'll keep reviewing the rest after that push. One thing to know before it can merge: this is a new package, so its first npm publish (and the trusted-publisher setup) is done by the maintainer.