A reviewable plan still needs a restricted environment
Plandex's appeal is its documented separation between generated changes and project files. For developers considering a large change, that creates a place to inspect the proposed work before applying it. It should not be treated as an operating-system sandbox.
The README describes plan version history, branches, configurable autonomy and optional automatic Git commits. It also claims a 2-million-token effective context window with the default model pack, roughly 100,000 tokens per file, and project maps for directories containing 20 million tokens or more. These are upstream capability claims. Our run did not measure context capacity, planning quality, edit accuracy, model cost or browser debugging.
What our recorded run establishes
Our recorded run began on September 28, 2026 at 03:00:16.738 UTC, using commit e2d772072efadbe41d2946d97d79be55532dbab5, abbreviated e2d7720. The command scope was ./app/cli. The recorded configuration was 3 CPUs, 8 GB of memory and image golang:1.24-bookworm. The image label does not verify the actual Go runtime version. The supplied record does not establish container privilege settings or secret handling.
The checkout measurements were 696 files, approximately 81,449 lines of source and 32.2 MB. Detection recorded one CI workflow and a test directory; neither establishes executed coverage.
| Recorded step | Result | What it supports |
|---|---|---|
| Install | Exit 0, 35 seconds; dependency count 360 | Step completion. The saved tail is empty, so it does not verify dependency downloads or binary installation. |
| Build | Marked successful, exit 0, 44 seconds | Build-step completion, qualified by the saved vet diagnostics. |
| Tests | Exit 0, 10 seconds | The saved output lists 17 CLI packages with no test files; the parser records 0 passed, 0 failed and 0 total. |
The raw build duration is 43.8 seconds, rounded to 44 in the summary. Its tail reports discarded context-cancellation functions at lib/apply_cgroup_linux.go:25:7 and cmd/browser.go:183:11, followed by vet-exit:1. The raw install and test durations are 34.5 and 10.434 seconds, respectively. Build-step success therefore should not be described as a clean vet result.
The go test result is not a failing test suite, and it is not evidence of passing behavioral tests. These are recorded parser summaries and output tails; no new execution or complete-log reconciliation established exhaustive unique coverage. We did not test the server, an installed binary, provider authentication or a measured coding workload. No audit result was recorded.
Local setup includes a server and model credentials
The local-mode quickstart describes a client-server architecture intended for a single local user. It requires Git, Docker and Docker Compose. The documented sequence clones the repository, changes into plandex/app and runs ./start_local.sh. A separate terminal installs the CLI, then runs plandex sign-in and selects the local host at http://localhost:8099.
The quickstart calls OpenRouter the quickest provider option and sets OPENROUTER_API_KEY. The README also permits other model-provider accounts and keys. These instructions explain the route to a session; our CLI build record does not verify that route end to end.
Windows support is through WSL. The README explicitly excludes Command Prompt and PowerShell. It also says Plandex Cloud began winding down on October 3, 2025 and stopped accepting new users. A new evaluation should therefore start with the local or self-hosted route rather than assume Cloud access.
The apply-path concern is a report, not our finding
Open issue 352 reports that model-controlled paths can cause applied changes to write outside the project directory. Its author identifies CLI version 2.2.1 and says they demonstrated the behavior through ApplyFiles. That is a third-party report; our recorded run did not reproduce it or establish its applicability to every build.
The supplied pull request 358 extract shows an open proposal to add containment checks for writes and deletes. An open proposal does not establish that a fix has shipped or that the proposed implementation is sufficient.
For an evaluation, use a restricted workspace, keep automatic apply disabled and inspect destinations before application. Manual approval alone is not proof of containment: issue 352 says the confirmation displays a file count without the destination paths. Treat the cumulative diff as a review feature rather than a security boundary.
Maintenance evidence supports caution, not an abandonment verdict
The supplied GitHub metadata records the last repository push as October 3, 2025 and marks the repository as neither archived nor disabled. The supplied release page labels cli/v2.2.1 as latest. Those observations establish a stale push date and an available release, not the maintainers' intentions or future support.
The open 2026 issue and proposed fix show community reporting and contribution. They do not establish maintainer responsiveness. Neither stars nor an updated repository metadata timestamp proves active code maintenance.
How to use the ratings
These are editorial evidence ratings, not benchmark results. On this five-point rubric, 1 means little supporting evidence or a major obstacle, 2 means material concerns or substantial unverified behavior, 3 means a documented route with meaningful setup or verification gaps, 4 means detailed evidence for the assessed dimension, and 5 requires broad corroboration and relevant verification. Unknown adoption and compatibility do not earn a high score.
Setup earns 3 because the local route is documented but includes a server and provider configuration that our run did not exercise. Documentation earns 3 because the supplied README and local quickstart explain that route, while broader production instructions were not verified here. Community earns 2 because reports and a proposed fix coexist with the old push date, without established maintainer responsiveness. Maturity earns 2 because the recorded build has vet diagnostics, behavioral operation remains unverified, and the apply-path report remains unresolved in the supplied evidence.
If you proceed, verify the current code and issue status first, then attempt a small change in a restricted project. Check the installed binary, server connection, generated destinations and resulting diff before considering a larger task. Aider's Git-centered workflow and OpenCode's separate plan agent are relevant alternatives, but we did not compare their performance or safety in this run.