Reasonix security fixes are prioritized for the currently developed Go rewrite and the current 1.x release line.

If you are unsure whether a version is affected, report against the newest released 1.x version and include the exact version or commit you tested.

Please report security issues privately. Do not open a public issue with exploit details, secrets, crash dumps, or proof-of-concept payloads.

Preferred reporting path:

1. Use GitHub private vulnerability reporting for this repository, if available.
2. If private reporting is not available to you, open a minimal public issue asking for a private maintainer contact path. Do not include exploit details in that issue.

Please include:

• Affected Reasonix version, commit, operating system, and installation method.
• The feature or surface involved, such as CLI, desktop app, HTTP serve, bot gateway, MCP plugin, built-in tool, updater, or configuration loading.
• Clear reproduction steps using dummy credentials and non-sensitive files.
• The expected impact, such as secret disclosure, arbitrary file access, command execution, sandbox escape, authentication bypass, or supply-chain risk.
• Any relevant logs with API keys, tokens, local paths, and personal data redacted.

Do not send real provider API keys, bot credentials, OAuth tokens, private workspace files, or third-party user data.

Reasonix is a local coding agent. Many features intentionally operate on the user's local machine and workspace, including file reads, file writes, shell commands, MCP plugins, language servers, bot sessions, and model-provider requests. A finding is security-relevant when it crosses a supported boundary or bypasses an explicit guard.

Supported boundaries include:

• Workspace confinement for file operations that are documented or implemented as workspace-scoped.
• Permission checks for tool calls, shell commands, file writes, and approvals.
• Sandbox behavior for built-in shell execution where the platform supports it.
• Secret handling for provider keys, bot credentials, OAuth tokens, plugin headers, and credential-store fallback files.
• HTTP serve protections, including the default per-launch token, the launch token every state-changing request requires when authentication is opted out, localhost binding assumptions, JSON-only state-changing requests, and CORS restrictions.
• Desktop and bot session isolation, including per-workspace session metadata and configured bot allowlists.
• Updater, install, and release verification paths.

The following are normally treated as trusted local/operator-controlled inputs unless another bug lets an untrusted actor supply them:

• CLI arguments and text typed directly by the local user.
• The user's own configuration under the Reasonix home directory.
• Explicit @path references supplied by the local user to attach local files.
• MCP servers, language servers, hooks, and slash commands installed, enabled, or approved by the local user.
• Provider base URLs and model names configured by the local user.

The following can be security issues when reachable by an untrusted actor or when they bypass the intended boundary:

• Reading or writing files outside the configured workspace without explicit local-user intent.
• Following symlinks or path traversal to escape workspace confinement.
• Running shell commands or external tools without the required permission gate.
• Leaking credentials, environment variables, prompt history, local files, or bot messages to logs, model providers, MCP servers, crash reports, or telemetry.
• Allowing a website to drive the local HTTP server through CSRF, CORS, or content-type bypasses.
• Letting a bot user outside the configured allowlist submit prompts, approve tools, or access a project workspace.
• Trusting unverified update artifacts, plugin definitions, or downloaded binaries.

Files that arrive with a workspace are untrusted input: reasonix.toml, .reasonix/settings.json, .mcp.json and the project .env. Cloning a repository is not a decision to trust its author, so these files may narrow what the user configured and never widen it.

An "always allow" answer, or extra write access, granted in a workspace is stored under the Reasonix home, not in the workspace.

Programs a workspace names for the host to run stay off until the user approves them for that workspace:

• Hooks, language server commands, tools.search.rg_path, tools.shell.path, [browser] and tools.system_one.laya.python are approved with reasonix trust, or for hooks by saving them from the hooks editor.
• An approval is stored under the Reasonix home with a digest of the declaration and of the workspace files it names; any change needs approval again. Approvals and grants belong to one workspace folder.
• Hooks and language servers are checked against their approval again before each start, and refused if a file they name changed, appeared or now resolves elsewhere.
• A single program path (tools.shell.path, tools.search.rg_path, [browser], laya.python) may not point into the workspace, an allow_write root, a temporary directory or a toolchain cache the bash jail leaves writable, and may not climb with ..; its approval covers the program file's content.
• tools.system_one.laya.local is read from the user's configuration only.
• Without an interactive frontend they stay off.
• MCP servers a workspace declares stay off until the user enables them for that workspace.

A project value that is not applied is reported as a load warning with the reason. A way for workspace files to widen any of the above without the user's approval is a security issue.

Reasonix supports @path references so users can include local files and images in a prompt. This is intentional local functionality, but implementations must preserve these invariants:

• In workspace-scoped sessions, relative and absolute paths must resolve under the active workspace root before file content is read or attached.
• Path traversal such as .. must not escape the workspace root.
• Symlinks must not be usable to bypass the intended workspace boundary.
• Unscoped local CLI compatibility must not be exposed to remote, bot, or browser-controlled inputs unless an equivalent workspace boundary is applied.
• File content should be size-limited and binary content should not be dumped as prompt text.

Static analysis alerts about path expressions should be triaged against these rules: user-controlled path data is expected, but the access must either stay inside the configured workspace or be clearly limited to trusted local CLI use.

The following reports are usually out of scope unless they demonstrate a bypass of one of the boundaries above:

• A local user intentionally asks Reasonix to read, edit, or send their own files to a configured model provider.
• A local user installs or enables a malicious MCP server, hook, slash command, language server, or shell command and then grants it permission.
• A configured model provider, proxy, or MCP server receives data the user intentionally sent to it.
• Denial-of-service issues that only affect the local user's own session and do not corrupt files, leak secrets, or bypass permissions.
• Issues requiring administrator/root access on the user's machine before interacting with Reasonix.
• Vulnerabilities in third-party services, models, proxies, or plugins that are not caused by Reasonix behavior.

This is a community-maintained project. Maintainers will make a best-effort assessment, ask follow-up questions when needed, and coordinate fixes before public disclosure for confirmed vulnerabilities.

Please give maintainers reasonable time to investigate and release a fix before publishing exploit details. If you plan to disclose on a timeline, include that timeline in your initial report.