jcode

jcode runs as the local user and uses whatever authority that user has. The shell tool starts every command with the background daemon's full environment, so provider API keys and any cloud or Git credentials in that environment reach every command the model runs, and the credential files jcode stores under the home directory are readable by those commands. MCP servers are the one path where jcode strips known provider credentials from the inherited environment. Optional Gmail access can be limited to a read-and-draft scope, but there is no general narrowing of the user's authority.

jcode has no human approval step for tool calls in its default configuration: the shell, file writes and network tools run as soon as the model calls them. The shell has a built-in destructive-command check that refuses commands it classifies as risky until the model re-sends them with a written justification, so the model can satisfy it by itself. A small set of targets (the root, the home directory and credential stores) is refused outright. An external pre-tool hook can block calls, but it is off unless the user configures it, and there is no undo or checkpoint for file changes.

The default tool set gives the model a general shell, file writes to any path, and fetching of any http or https URL. The shell command check classifies commands by what they would destroy and refuses a small set of catastrophic targets, which is a filter rather than an allowlist. File tools accept absolute paths anywhere on disk, and the web fetch tool checks only the URL scheme, with no block on internal or metadata addresses. A per-session allow or deny list of tools exists for SDK and swarm sessions, but the interactive default enables everything.

Model-written shell commands run directly on the host as the user through bash, in the session's working directory. There is no container, OS sandbox profile or separate low-privilege user anywhere in the codebase, and MCP servers, background jobs and hooks also run as ordinary host processes. A timed-out command is moved to the background rather than killed.

jcode reads web pages, search results, repository files, MCP tool results and swarm messages straight into the model's context, with no marking of where content came from and nothing that changes what the agent may do afterwards. Because tools run without approval, injected instructions in any of these sources can drive the shell and the web fetch tool in the same session. A hijacked session can therefore both send data out and take irreversible actions with no person involved. A few helper prompts tell sub-models to treat page content as untrusted, which is guidance only.

Several files in the working directory are loaded automatically with no trust prompt: project MCP config files (in jcode's own format and Claude Code's), a project system prompt file that replaces the built-in system prompt, AGENTS.md, prompt overlays and project skills. Project MCP servers are enabled unless marked disabled and are started when the session begins, so a cloned repository can add tools that run as the user. The model can also write long-term memories at project or global scope with no validation, and those memories are recalled into later sessions. Memories are stored per project, and a single user's sessions share them.

MCP servers are launched from user config, from Claude Code's config files and from project config files in the working directory, using whatever command and package version the config names, with no pinning, hash check or re-approval when a server changes. Project-level MCP servers are enabled automatically. Each server runs as a separate process as the user; jcode removes known provider credentials from the environment it passes, but the process can still read the user's files.

Credentials that jcode stores are written to files with owner-only permissions, and its log writer redacts fields that look like keys or tokens. Saved session transcripts are kept unredacted on disk; redaction is applied only to the optional transcript upload. Anonymous usage telemetry is on by default and described as content-free, with full transcript sharing a separate opt-in. Long-lived provider keys in the daemon environment reach every shell command the model runs.

Every tool call goes through one registry that writes structured start, done, error and blocked events with session, message and tool-call identifiers, touched paths and timings to a daily log under the jcode home directory, and full arguments and results are kept in the saved session. The log is flushed per line and errors are reported. There is no separation between agent and human actions, and the shell tool can edit or delete the log because it runs as the same user.

The agent loop has no cap on steps, tool rounds or spend in the default configuration; it runs until the model stops or the user cancels, and cancellation is checked between steps. Shell commands have a two-minute default timeout, but a command that exceeds it is moved to the background instead of being killed, and background commands have no timeout unless the model sets one. Swarms are limited to 32 concurrently running workers by default, with an absolute ceiling of 1000. A daily token budget exists only for the optional ambient mode.