| FMRS | 56 / 100 · C | 79 / 100 · B |
| Reliability | 8 / 20 | 12 / 20 |
|---|
| Security and permissions | 9 / 20 | 18 / 20 |
|---|
| Maintenance | 12 / 20 | 16 / 20 |
|---|
| Documentation | 14 / 20 | 18 / 20 |
|---|
| Setup experience | 13 / 20 | 15 / 20 |
| Best for | - Statisticians and data scientists working in RStudio or Positron who want an agent operating on their live session.
- Researchers who need to audit the numeric and citation consistency of their own or others' manuscripts.
- Developers and researchers who want to orchestrate multi-agent workflows on their existing model subscription.
- Users who prefer local sessions, auditable logs, and zero-config uvx startup.
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
| Not for | - Anyone exposing the R session on an untrusted network or a shared machine: binding to 127.0.0.1 is not a security boundary.
- People who need sandboxed code execution: the guardrail is a regex blocklist, not a sandbox, and is trivially bypassable.
- Users unwilling to accept prompt-injection risk when auditing third-party documents.
- People who only want editor and audit tooling from a Python session: those tools drive the IDE through rstudioapi and have no Python equivalent.
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
| Required permissions | - Execute arbitrary R code in the live R session (via execute_r and related tools).
- Read any file your account can read (read_file, get_viewer_content, and others).
- Write to and save files open in your editor (modify_code_section, insert_text).
- Install R packages, overwrite objects in your environment, make network calls, and consume compute.
- Listen on a local port (default 8787) and write session discovery files under ~/.claude_r_sessions/; when a token is enabled that file is written with mode 0600.
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
| Risks and side effects | - Binding to 127.0.0.1 is not a security boundary: other local processes, and even any webpage you visit, can POST code to the port, which is arbitrary code execution in your session. ClaudeR always rejects requests carrying an Origin header with a 403, and offers an opt-in session token (X-Clauder-Token).
- The session token is off by default because enforcing it rejects any bridge older than clauder-mcp 0.6.0, so the local-process vector stays open until you enable it.
- validate_code_security() is a regex blocklist (system(), system2(), shell(), rstudioapi::terminal, recursive/wildcard deletes) and is trivially bypassable via get("system")(...), do.call, or eval(parse(...)). It is a seatbelt, not a sandbox.
- Prompt injection: combining tools that pull untrusted third-party content (read_file, get_viewer_content, verify_references, load_annotation_data) with arbitrary R execution, file writes, and network access means a manuscript, CSV, or HTML widget authored by someone else is untrusted input on a path to code execution. Auditing someone else's manuscript is the riskiest shape.
- The agent can read any file you can read, install packages, and make network calls; work in a project directory and keep credentials out of the working directory.
- Async jobs run in a separate R process via callr and do not have access to the main session's environment; the agent must write self-contained code using saveRDS, and misuse leads to inconsistent results.
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
| Supported clients | Claude Desktop, Claude Code, Codex, Qwen Code, Antigravity, Gemini CLI, Cursor | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
| Tools | 37 | 0 |