fix(node-sdk): forward --agent/--agent-file to the v2 engine on session creation - #3855
ZhangWanqiang wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 75162f1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
b64153f to
86819c0
Compare
86819c0 to
8e5566e
Compare
|
Hi maintainers! 👋 This is my first contribution to this repo, so the workflow runs on this PR are stuck in the "action_required" state waiting for approval. Could someone please click "Approve and run workflows" in the Checks tab so CI can run? Also, this PR fixes a regression with no linked issue — please let me know if I should create one first for the |
cbc534d to
748f6d9
Compare
|
Hi maintainers! 👋 |
|
Hello @Grapedge , sorry for interrupting you, this is a fix about kimi-code agent, (also my first PR in github). i am waiting for the feedback from the maintainers and I am confused about the merge flow. I see your PRs were approved and merged successfully. Can you help checking what is the problem of my PR ？ Thank you. |
748f6d9 to
4c6c640
Compare
…on creation The v2 SDK client dropped CreateSessionOptions.agentProfile and .agentFiles at the engine boundary: session creation always bound the default profile and explicit agent files never reached the explicit agent-profile loader, so the interactive CLI ignored both flags (print mode kept working because it drives the engine in-process). Thread agentProfile into the main-agent materialization bind, and feed agentFiles to the engine's explicit agent-profile source (bootstrap args plus a reload of the target workspace's explicit loader) before the session materializes. Program exposes its explicit loader for that reload.
4c6c640 to
75162f1
Compare
This branch has not been deployed
1 participant
Related Issue
No linked issue — regression introduced by the v1→v2 engine migration (the v2 SDK client never forwarded the fields).
Problem
kimi --agent <name>and--agent-file <path>had no effect when starting the interactive CLI. The flags were parsed and carried all the way into the TUI's firstcreateSessioncall, but the v2 SDK client dropped them at the engine boundary: session creation always bound the default agent profile, and explicit agent files never reached the engine's explicit agent-profile loader. (kimi -p --agent ...kept working because print mode drives the engine in-process and passes both through.)Repro on 0.43.1:
kimi --agent reviewer(withreviewer.mdin the user agent directory or via--agent-file) starts the TUI with the default agent; the named profile is never bound.What changed
SDKRpcClientV2.doCreateSessionnow consumesagentProfile: it is threaded into the main-agent materialization, which binds that catalog profile instead of the default. An unknown name fails at creation withprofile.unknown(matching v1's create-time validation), and specifying only--agentnow materializes the main agent instead of leaving it lazy.agentFilesare appended to the bootstrap-args list that the engine's explicit agent-profile source reads on every load, and the target workspace's explicit loader is reloaded before the session materializes. The explicit loader is fatal, so an unreadable/invalid file rejects session creation up front instead of being silently skipped.Programexposes its explicit agent-profile loader (already constructed per generation) so the SDK can trigger that reload.--agent-fileand binding the profile it defines, rejecting an unknown profile name, and the no-flag default-profile baseline.Verified manually with a locally built 0.43.1 + this patch: the TUI starts with the requested custom agent.
Checklist
/approve).gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.