# Easy Code ships a Gemini CLI Makefile, a DeepV dev script and a clone URL with two Cs

> Easy Code is a TypeScript coding assistant published as the npm package easycode-ai, with a CLI, a VS Code plugin, MCP support, hooks and a fixed built-in tool set. Underneath the feature documentation sit several artefacts that have not been renamed: a Makefile whose header and targets still refer to the Gemini CLI, dev scripts pointing at deepvlab.ai endpoints, a brand notice that keeps the old identifiers for compatibility, and a source-build clone URL spelled with one C too many.

**OrionStarAI/EasyCode** — Easy Code (formerly DeepV Code) — A highly customizable AI coding assistant compatible with all major AI models. The perfect alternative to Claude Code and Codex, offering deep code analysis, intelligent suggestions, version rollback, multi-device sync, and automated testing across multiple languages and platforms.

- Repository: https://github.com/OrionStarAI/EasyCode
- Website: https://easycode.bot
- Stars: 422 · Forks: 47
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/orionstarai-easycode

## The Makefile header says gemini-cli and its targets still run it

The most revealing file in the repository is the Makefile, and it does not mention Easy Code once. Its own comment reads Makefile for gemini-cli. The help target echoes the same thing back, describing make start as starting the Gemini CLI and make debug as starting it in debug mode. The run-npx target is worse, because it is not a description but a command: it runs `npx https://github.com/google-gemini/gemini-cli`, so a developer who follows that line installs and launches a different program entirely. The create-alias target creates a `gemini` alias for the shell.

The package metadata points the same way. The `config` block in package.json sets a sandbox image URI of `us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.1.13`, so the --sandbox flag on the CLI runs a container image published by the Gemini CLI project rather than one built here.

None of this makes the tool unusable, and it is not evidence of anything worse than an incomplete rebrand. It does mean the Makefile cannot be trusted as a description of the project, and that a sandbox boundary drawn from another codebase inherits that codebase's contents. The rest of the targets, install, build, build-all, test, lint, format, preflight and clean, all delegate to npm scripts and behave as expected.

What the Makefile does not contain is a release target, even though the .PHONY list names one.

## A rename notice that keeps the old names on purpose

The README opens with a brand upgrade notice. It says the project has been renamed and that, during a transition period, the package name, the command name and the configuration directory deliberately keep their previous forms for backwards compatibility: `easycode-ai` for the package, `easycode` for the command, and `.easycode/` for the config directory. New documentation and the interface are supposed to use the new branding.

The repository description carries the other half of that history, calling the project formerly DeepV Code. The tree still has the paperwork: DEEPV.md and DeepV_Code_Whitepaper.md at the root, alongside a run of other loose documents such as SKILL_MIGRATION.md, DEBATE_I18N_QUICKREF.md, RELEASE_NOTES_FEISHU.md and DELIVERY_CHECKLIST.md.

The build scripts are where the old identity is still load bearing. The dev and debug scripts set two environment variables before starting the server, `DEEPX_SERVER_URL=https://api-code.deepvlab.ai` and `DEEPX_WEB_URL=https://dvcode.deepvlab.ai`, so a development run talks to a deepvlab.ai backend by default and `npm start` does not. Anyone reproducing a bug locally needs to know which of the two entry points they are on.

The npm identity is unambiguous otherwise: the package is `easycode-ai` and the verification step after install is `easycode --version`.

## The source install path clones a URL with an extra C

There are two documented ways in, and the second one has a typo in it.

The package route is straightforward, and npm is the recommended one, with yarn and pnpm given as equivalents for the same global install:

```bash
npm install -g easycode-ai
yarn global add easycode-ai
pnpm add -g easycode-ai
```

The source route is a five step list, and step one is the problem:

```bash
git clone https://github.com/OrionStarAI/EasyCodeCode.git
cd EasyCode
npm install
npm run build
npm run dev
npm run pack:prod
```

The clone URL spells the repository EasyCodeCode, with C doubled, while the directory you land in is EasyCode and the repository field in package.json is `git+https://github.com/OrionStarAI/EasyCode.git`. The build itself is ordinary: install, build, then `npm run dev` for a development run or `npm run pack:prod` for a production bundle.

System requirements are short and stated up front: Node.js 20.0.0 or newer, Windows, macOS or Linux, and a terminal that renders ANSI colour. The last of those is worth taking seriously, since the interface is a full screen terminal application with themes.

So the fix for anyone following the README literally is one character, and the fix for anyone testing the published package is to skip this section entirely.

## Thirteen global flags, one of which removes every confirmation

The CLI reference is a table of global options, and it is complete enough to plan an automation around. Model selection is `--model <name>` with the short form `-m`. Non interactive work is `--prompt <text>` with `-p`, and `--prompt-interactive <text>` with `-i` runs the prompt and then drops into the session. There is a `--sandbox` and `-s` for running inside the sandbox image, `--debug` and `-d` for verbose logs, and `--all-files` and `-a` to put every project file into context.

Session control is three flags rather than one: `--continue` and `-c` resumes the last session, `--session <id>` resumes a named one, and `--list-sessions` prints what exists. `--workdir <path>` sets the working directory, and `--version` and `--help` are the usual pair.

Then there is `--yolo` and `-y`, described as YOLO mode, which executes all operations without confirmation, and the README's own example marks that line as dangerous. The same switch exists inside a session as `/yolo [on|off]`, and its opposite is `/plan [on|off]`, a mode that discusses without modifying code. Having both a flag and a slash command for the same two modes means the risky one can be turned on at launch and toggled later without restarting, which is convenient and also means a session started in the wrong mode stays wrong.

A single model switch looks like this:

```bash
easycode -m gemini-2.0-flash
```

## Hooks fire at four named points in the tool loop

The extensibility story has three layers and the first is hooks, which inject your own logic at specific workflow points. There are exactly four, and they are named after when they run: PreToolExecution before a tool executes, PostToolExecution after it, OnSessionStart when a session begins, and OnSessionEnd when it ends.

Four points is a small, legible surface. PreToolExecution is the one that can block or reshape a call, PostToolExecution is the one that can run a formatter over what just changed, and the two session points are where setup and teardown logic belongs. The stated uses are automated code checks, formatting, and validation before a commit, which is the category of work that otherwise gets skipped when a session ends abruptly.

The second layer is MCP, and it is treated as a core feature rather than an add on. The README frames it as a global project view covering file structure, module dependencies and code semantics, cross file analysis that follows call chains, type references and imports and exports, automatic selection of the files and code segments relevant to a task, and connections to third party MCP servers for outside data and tools.

The third is skills, named alongside hooks and MCP servers in the extensibility summary. A migration document for moving to skills sits at the root of the repository, SKILL_MIGRATION.md, which suggests the mechanism is recent enough to have needed a migration note.

## Checkpoints roll back files, and sessions survive a restart

Session management is four separate promises, and the fourth is the one that matters most in practice.

The first is persistence: conversation history and context are saved automatically. The second is recovery, so you can continue earlier work at any time. The third is history compression, which compacts the conversation to reduce token consumption, and that is also what the `/compress` slash command does. All three are available as flags or commands, with `--continue` and `--session <id>` on the command line and `/session` in the session, where it takes `list`, `new`, `select <id>` or `rebuild`.

The fourth is checkpoint restore, where file modifications can be rolled back to a previous state. In the session that is `/restore [id]`, and the README also promises a `/trim-spaces [on|off]` toggle for stripping trailing whitespace, plus `/refine <text>` with `--tone`, `--lang` and `--level` options for rewriting text.

The distinction between the two is worth being precise about, because they are often conflated. Rolling back a file is not the same as rolling back a conversation, and the session list is a record of what was said rather than a snapshot of what was on disk. A checkpoint is what protects the repository; the session is what protects the thread.

The rest of the command surface is small and mostly self describing: `/help`, `/help-ask`, `/issue` for filing a GitHub issue with the error log attached, `/stats`, `/tools`, `/mcp` with `add`, `auth` and `refresh`, `/memory` with `show`, `add` and `refresh`, `/vim`, `/copy`, `/clear`, `/theme`, `/editor` and `/about`.

## The built-in tool set is a fixed list of names

The tool surface is enumerated rather than described, which makes it easy to see what an agent can reach. File operations are `read_file`, `write_file`, `replace`, `delete_file` and `glob`. Code search is `grep`, which is ripgrep, plus `read_many_files`. Command execution is `shell`, which covers both bash and powershell. Network access is `web_fetch` and `web_search`, the latter noted as Google.

Then four tools that are more than plumbing. `task` launches an analysis sub agent, so a question about one subsystem can be answered in a context of its own. `todo_write` is the task list, which is what makes a multi step request trackable. `memory` is a long term memory, managed inside a session with `/memory` and its `show`, `add` and `refresh` subcommands. And any tool provided by a connected MCP server is callable the same way, so the list above is the floor rather than the ceiling.

`delete_file` and `shell` in the same set is the combination that decides how much you trust a session, and the confirmation model is what stands between them and a repository. Sensitive operations are supposed to require user confirmation, `/plan [on|off]` is the mode where nothing is modified, and `/yolo` is the switch that removes the confirmation entirely.

There is also a debug console on `Ctrl+O`, cycling through three states: all logs, then errors only with a marker showing the filter is active, then closed. It is the first thing to open when a session stops behaving, and the filter exists because the third state is reached by pressing the same key twice.

## Four workspace packages, and a version behind its own tags

package.json declares four workspaces: `packages/cli`, `packages/core`, `packages/vscode-ui-plugin` and `packages/desktop`. The split matches the surfaces the README describes, with the VS Code plugin as its own package built by its own script, `node scripts/build_vscode_companion.js`, and folded into the full build behind the `INCLUDE_VSCODE_PLUGIN=true` flag. The plugin is also why the README links to the VS Code marketplace and why the desktop package exists alongside a terminal application.

The build surface is wide: start, dev, debug, generate, build, build:all, build:vscode, build:packages, build:full, build:sandbox, and an auth chain that runs `npx google-artifactregistry-auth` followed by `gcloud auth configure-docker us-west1-docker.pkg.dev`. That last pair is a Google Cloud artifact registry login, which lines up with the sandbox image living in that same registry.

The version is where the metadata stops agreeing with itself. package.json says 1.1.14, while the release tags are v1.1.27 on 17 June 2026, v1.1.16 on 11 June and v1.1.12 on 9 June. So the published package version and the newest tag differ, and a checkout of main can be older than the last release. Node 20.0.0 is the engine floor, the type is module, and the licence is Apache-2.0 with both LICENSE and NOTICE present.

The last push to the opensource branch is dated 17 June 2026, the same day as the v1.1.27 tag. The root also carries a .gitlab-ci.yml beside .github/, plus a temp/ directory and a build_output.txt, which is more working state in the repository than most projects keep.

## Conclusion

Easy Code fits someone who wants a self-hosted agent CLI with project wide context, hooks at four named points and rollback on file edits, and who is willing to read the source build path carefully. It does not fit someone who needs a project whose internals match its documentation, since the Makefile, the dev endpoints and the clone URL all point somewhere other than the branding. Before building from source, compare the clone URL against the repository URL in package.json, check which package version is actually published against the release tags, and decide whether the sandbox image borrowed from the Gemini CLI is the isolation boundary you want before reaching for --sandbox or --yolo.

## FAQ

### What is easycode?

In this repository it is an Apache-2.0 TypeScript coding assistant published to npm as easycode-ai and driven by the easycode command, requiring Node.js 20.0.0 or newer. It is described as an agent rather than a completion tool, with project wide context, a built-in tool set, hooks, MCP server support, skills, session checkpoints and a VS Code plugin.

### Does easycode have a VS Code plugin?

There is one, in its own workspace package called packages/vscode-ui-plugin. It is built by a separate script, node scripts/build_vscode_companion.js, and is included in the full build by setting INCLUDE_VSCODE_PLUGIN=true.

### What do the Easy Code hooks do and when do they run?

There are four, named for their timing: PreToolExecution before a tool runs, PostToolExecution after it, OnSessionStart and OnSessionEnd. The stated uses are automating code checks, formatting, and validation before a commit.

### How do I build Easy Code from source?

The README lists git clone of a URL spelled OrionStarAI/EasyCodeCode.git, then cd EasyCode, npm install, npm run build, npm run dev, and optionally npm run pack:prod. The package metadata points at a different spelling, OrionStarAI/EasyCode, which is the one to use. For the published package, npm install -g easycode-ai is the recommended route.

### What does the yolo mode in easycode turn off?

It removes the confirmation step: the flag --yolo, short form -y, executes all operations automatically, and the README marks that example as dangerous. The same mode is available inside a session as /yolo [on|off], and /plan [on|off] is its opposite, a mode that discusses without modifying code.

### Can easycode roll back file changes?

Yes. Checkpoint restore lets file modifications be rolled back to an earlier state, and /restore [id] restores files to a checkpoint inside a session. Session state is separate: --continue resumes the last session, --session and --list-sessions handle named ones, and /session takes list, new, select or rebuild.

## Sources

- [License: Apache-2.0](https://github.com/OrionStarAI/EasyCode/blob/opensource/LICENSE)
- [OrionStarAI/EasyCode on GitHub](https://github.com/OrionStarAI/EasyCode)
- [Project website](https://easycode.bot)
- [README](https://github.com/OrionStarAI/EasyCode/blob/opensource/README.md)
- [Releases](https://github.com/OrionStarAI/EasyCode/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/orionstarai-easycode