`dcode` now gives clearer messages when managed ripgrep is unavailable
for the current system or missing from the pinned upstream artifacts,
and POSIX managed ripgrep installs now use a relative symlink to a
versioned binary for better portability.
---
Managed ripgrep setup used to collapse permanent gaps and transient
download failures into the same generic failure path. This makes those
cases distinct and makes POSIX managed installs more portable.
## Before
- As a user on an unsupported system, I saw a generic managed ripgrep
install failure and could not tell whether retrying would help.
- As a user whose pinned managed ripgrep artifact was missing upstream,
I saw the same kind of failure as a network outage.
- As a user who moved, restored, or bind-mounted `~/.deepagents`, a
managed helper link could bake in the old absolute path or become stale.
- As a user with a broken managed `rg` symlink, dcode could fall back to
another `rg` on `PATH` instead of repairing the managed install.
## After
- As a user on an unsupported system, I get a direct message that
managed ripgrep is not available for my platform and can install ripgrep
manually or opt into the system installer path.
- As a user whose pinned managed ripgrep artifact returns HTTP 404, I
get a message that the artifact is unavailable for the pinned version,
instead of a generic network failure.
- As a user with transient download trouble, I still get the normal
download-failure path and can retry.
- As a user who moves or bind-mounts `~/.deepagents`, the `rg`
entrypoint is a relative symlink to a versioned managed binary, so it is
less fragile.
- As a user with a dangling managed `rg` symlink, dcode treats it as
managed state and repairs it rather than silently substituting a system
binary.
`dcode tools install` provisions the managed ripgrep binary; the install
script now sets it up by default (opt out with
`DEEPAGENTS_CODE_RIPGREP_INSTALLER=system` or
`DEEPAGENTS_CODE_OFFLINE=1`).
---
Today the pinned, SHA-256-verified ripgrep binary only lands on first
run (via `managed_tools.ensure_ripgrep`), so a fresh user pays a
one-time download the first time they launch. This makes the install
script provision it eagerly so `rg` is ready immediately, without
reaching for `sudo` package managers by default.
Rather than re-encoding the pinned version + checksum table in bash
(drift risk), a new `dcode tools install` verb reuses the existing
managed-install code, and `scripts/install.sh` invokes the freshly
installed binary. The verb is also handy on its own to repair a missing
or stale `rg`.
Power users can keep their own toolchain with
`DEEPAGENTS_CODE_RIPGREP_INSTALLER=system`, which preserves the existing
brew/apt/cargo path in the install script and skips the managed download
at runtime. A system `rg` already on `PATH` is reused under either
setting, and `DEEPAGENTS_CODE_OFFLINE` / `DEEPAGENTS_CODE_SKIP_OPTIONAL`
continue to apply. The default eager install is announced and honors
those opt-outs, per the package's "default shell-outs must announce +
offer a documented opt-out" rule.
---------
Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
Closes#3120
Auto-installs a pinned `ripgrep` binary on first run when one is not on
`PATH`. Set `DEEPAGENTS_CODE_OFFLINE=1` to disable.
---
On first launch without a system `rg`, Deep Agents Code now downloads a
pinned upstream ripgrep release, verifies its SHA-256 against an in-tree
table, and installs it into `~/.deepagents/bin/`. In the interactive
TUI, `_start_server_background` awaits the one-shot install
(`_ensure_managed_ripgrep`) and prepends `~/.deepagents/bin/` to `PATH`
**before** spawning the langgraph server subprocess — which snapshots
`os.environ` — so the SDK's existing `subprocess.run(["rg", ...])`
resolves the managed binary with no SDK change. The headless
(non-interactive) path installs inline in `cli_main` before launching
the agent.
The managed binary is re-checked on every startup against
`RIPGREP_VERSION` (one `rg --version` probe, ~10ms) so bumping the pin
in source automatically triggers a re-download.
`DEEPAGENTS_CODE_OFFLINE` opts out of network access entirely and
preserves the existing missing-tool notification + slow Python regex
fallback.
A SHA-256 mismatch on the downloaded archive raises a dedicated
`ChecksumMismatchError` and aborts the install with a loud, user-visible
notice rather than being silently treated as "offline" — a mismatch is a
supply-chain anomaly, not a connectivity problem.
The Windows ARM entry points at the x86_64-pc-windows-msvc asset —
upstream doesn't ship an arm64-windows build for ripgrep, and Windows on
ARM runs x64 binaries via emulation. T11 in `THREAT_MODEL.md` documents
the new network egress and the in-tree SHA-256 verification.
_Opened collaboratively by Mason Daugherty and open-swe._
---------
Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
Co-authored-by: Mason Daugherty <61371264+mdrxy@users.noreply.github.com>
Co-authored-by: Mason Daugherty <mason@langchain.dev>
Co-authored-by: Mason Daugherty <github@mdrxy.com>
Mason Daugherty