Add a documented safe-evaluation profile for first-time jcode users

Feature request

jcode is a powerful coding-agent harness with high-trust capabilities: shell execution, file writes, browser automation, Gmail integration, OAuth/provider credentials, MCP tools, persistent memory, telemetry, and ambient/autonomous modes.

That is expected for a capable coding agent, but it also means first-time users need a clear and easy way to evaluate jcode safely before running it against their main machine, primary credentials, or sensitive repositories.

It would be useful to document and/or provide a built-in "safe evaluation profile" for new users.

Suggested behavior

Add a documented setup path, command, or profile that makes it easy to run jcode with conservative defaults, for example:

• isolated JCODE_HOME
• telemetry disabled
• no Gmail integration
• no browser automation with a personal browser profile
• no ambient/autonomous mode
• no self-dev mode
• no MCP servers loaded by default
• explicit confirmation for shell, write, patch, open, webfetch, browser, and external communication tools
• clear warning before importing credentials from other tools
• guidance to use a disposable repo/worktree/container/VM for first evaluation

Example:

export JCODE_NO_TELEMETRY=1
export DO_NOT_TRACK=1
export JCODE_HOME="$HOME/.jcode-sandbox"
mkdir -p "$JCODE_HOME"
chmod 700 "$JCODE_HOME"
jcode --safe-eval

The exact interface could be different, but the goal is to make the cautious path obvious.

Why this matters

jcode's power comes from combining many high-impact capabilities:

• shell execution
• file modification
• provider/OAuth credentials
• browser automation
• Gmail actions
• webfetch/websearch
• persistent memory/transcripts
• MCP/tool integrations
• ambient or autonomous operation

Even if each subsystem has reasonable safeguards, the combined surface area is large. New users should not have to reverse-engineer the safest first-run configuration.

A safe-evaluation mode would help users test jcode without immediately trusting it with:

• primary provider accounts
• personal browser sessions
• Gmail access
• sensitive repositories
• long-lived local memory
• ambient/autonomous behavior

Possible MVP

A small MVP could be documentation-only:

1. Add a "Safe first run" section to the README or docs.
2. Recommend isolated JCODE_HOME.
3. Recommend telemetry opt-out for sensitive testing.
4. Recommend disposable repos/worktrees.
5. Explain which tools are high-impact.
6. Explain which integrations should be avoided during first evaluation.

A stronger version could add a built-in flag:

jcode --safe-eval

or:

jcode setup --profile safe-eval

This profile could:

• create/use an isolated home directory
• disable telemetry
• disable ambient/selfdev
• skip credential auto-import
• skip Gmail/browser/MCP setup
• require explicit approval for all high-impact tools
• print a short summary of what is disabled

Related hardening ideas

These could be separate follow-up issues:

• document whether release binaries are verified by checksum/signature
• provide checksums/signatures for install artifacts
• make curl | bash install path more auditable
• document process-tree cleanup behavior for shell commands
• add a command to inspect local memory/transcripts and purge them
• add a command to audit current enabled tools/integrations

Start with the README or existing docs and review the documented setup around JCODE_HOME, telemetry, credentials, and high-impact tools. Compare the documentation-only MVP with a built-in --safe-eval or setup profile. Done means the cautious first-run path, disabled integrations, confirmations, and disposable-environment guidance are clearly specified and documented.