Follow up to #1911. The initScripts half of that ask shipped through the runtime in github/copilot-agent-runtime#12710, but the per-session env part was deferred out of that PR.
Context: microsoft/vscode#323164
initScripts covers the Python activation case since the host can materialize a shell-specific activation file and have the runtime source it before each command. An explicit env map is still worth having for hosts that just want to set or unset a few variables without generating script files, and without dealing with per-shell quoting.
Current wire shape:
export interface ShellOptions {
initProfile?: "none" | "non-interactive";
initScripts?: ShellInitScript[];
processFlags?: string[];
}
Add the env map from the original proposal:
export interface ShellOptions {
/** Env applied to built-in shell tool child processes. `null` unsets/removes. */
env?: Record<string, string | null>;
}
The reason this was deferred is that the update semantics should be pinned down before the wire shape ships:
- Whether
session.rpc.options.update with shell.env replaces the whole overlay or merges per key. Replace seems right: it stays idempotent and a host can revert a variable to the inherited value by omitting it. With merge there is no way to un-touch a variable once set.
- Precedence: overlay applied to the spawned process env first,
initScripts sourced after, so scripts can override.
null meaning remove-from-env vs revert-to-inherited.
- Whether the overlay persists across resume or the host re-sends it, matching how the rest of
shell behaves today.
(generated by copilot)
Follow up to #1911. The
initScriptshalf of that ask shipped through the runtime in github/copilot-agent-runtime#12710, but the per-sessionenvpart was deferred out of that PR.Context: microsoft/vscode#323164
initScriptscovers the Python activation case since the host can materialize a shell-specific activation file and have the runtime source it before each command. An explicit env map is still worth having for hosts that just want to set or unset a few variables without generating script files, and without dealing with per-shell quoting.Current wire shape:
Add the
envmap from the original proposal:The reason this was deferred is that the update semantics should be pinned down before the wire shape ships:
session.rpc.options.updatewithshell.envreplaces the whole overlay or merges per key. Replace seems right: it stays idempotent and a host can revert a variable to the inherited value by omitting it. With merge there is no way to un-touch a variable once set.initScriptssourced after, so scripts can override.nullmeaning remove-from-env vs revert-to-inherited.shellbehaves today.(generated by copilot)