不可变的 DeepSeek Harness 启动环境快照,按层级(进程环境/项目 .env/用户 .env)记录变量来源,允许按信任顺序查询变量值而非直接使用 process.env,用于需要区分环境变量可信度的场景
ⓘ 此插件是大仓库 deepseek-ai/deepseek-harness 的子包,星数与活跃度统计的是整个仓库。
- 语言
- TypeScript
- License
- MIT
- 分支
- master
安装
$ dsh plugin --profile web add npm:@deepseek-ai/dsh-launch-environment在终端中运行以上命令,通过 dsh CLI 安装此插件。可在右上角切换 Profile。 第一次用 dsh?看这篇新手教程
对话式安装
帮我安装 DeepSeek Harness 插件 deepseek-ai/deepseek-harness/packages/util/launch-environment:先查看仓库 https://github.com/deepseek-ai/deepseek-harness 确认安全性,然后执行安装命令并验证插件加载成功。
把这段指令粘贴给 DSH Web GUI 里的助手,由它代你完成安装与验证。
English | 中文
This run's environment as one immutable snapshot that remembers which layer supplied each value. Consumers resolve user-facing values against it instead of process.env, because the layers are not equally trusted and a flattened view cannot tell them apart.
| Layer | Source id | What it is |
|---|---|---|
| Inherited process environment | process | What the launching shell, CI job, or container passed in — this run's explicit intent |
<invocation cwd>/.env | project-env | The project the harness was launched in, which the product trusts to configure its own agent |
$DSH_HOME/.env | user-env | The user's own machine-level defaults |
Values do also reach process.env — a user's --config tree and third-party libraries read it — but that flattened view is not the authority for anything the harness resolves.
Resolving
get(name) searches every layer, most trusted first. getFrom(name, sources) searches only the named layers without changing that trust order.
Omitting a layer is a refusal, not a demotion — a caller that must never accept a layer leaves it out of the list, so no future reordering can let it back in. The provider adapters name all three, because the product trusts the project it runs in; the mechanism exists for the decisions where that is not true.
Names match the way the platform matches them: exactly on POSIX, case-insensitively on Windows. A case-sensitive lookup there would rank the wrong layer — a shell's deepseek_api_key and a project .env's DEEPSEEK_API_KEY are one variable to the OS, and treating them as two would let the project win.
import type { Context } from '@deepseek-ai/cordis'
import { launchEnvironmentOf } from '@deepseek-ai/dsh-launch-environment'
declare const ctx: Context
const endpoint = launchEnvironmentOf(ctx).get('DEEPSEEK_BASE_URL')?.value
launchEnvironmentOf(ctx) returns the launcher's snapshot when the product CLI booted the tree, and otherwise the inherited environment as the only layer. That fallback does not weaken the rules: an SDK host or a bare cordis.yml discovered no files, so everything it has really is the environment it was launched with.
Known Limitations and Deferred Work
- The snapshot is not a subprocess boundary — every layer is also materialized into
process.env, so ordinary project variables reach child processes underdsh-subprocess's scrub. The product launcher's.envcontract rejects bootstrap variables before materialization. - No per-workspace layer — the project layer is the invoking directory, fixed at launch. A workspace selected later in the Web UI contributes nothing, deliberately: following it would let a model's own workspace change the harness environment mid-session.
查看使用指南 →
该插件的安装步骤、关键要点、FAQ 与兼容性说明(基于已收录字段派生)。
收录徽章
[](https://deepseek-plugin.org/plugins/deepseek-ai/deepseek-harness/packages/util/launch-environment)把这段 markdown 粘贴到你的 GitHub README,链接回本插件详情页。徽章只声明已被本站收录,不代表安全认证。