Tools Reference

The primary discovery tool. Always use before Grep or Glob. code (the default) ranks candidates with SQLite FTS5/BM25 (services/lexical_index.py, stored in .c3/index/index.sqlite) and fuses them with the embedding index by reciprocal rank fusion (Σ 1/(k + rank), k=60) once the dense backend is warm — action='lexical' returns the BM25 ranking alone, with no fusion. The tokenizer keeps identifiers whole and split with digits intact (sha256_digest indexes as sha256_digest sha256 digest; v2, S256 are tokens) and applies no stemming. A query that IS a symbol name puts its definition first. An oversized chunk comes back as a bounded window instead of being skipped.

Examples

# Find code by content (fused BM25 + dense)
c3_search(query='session snapshot restore', action='code')

# BM25 ranking alone, no fusion
c3_search(query='session snapshot restore', action='lexical')

# Find files by name/path
c3_search(query='hook files in cli/', action='files')

# Semantic similarity search
c3_search(query='code that handles authentication expiry', action='semantic')

# Exact regex match, case-insensitive, scoped to Python source
c3_search(query='class.*Manager', action='exact', ignore_case=True, lang='python', top_k=10)

# Filtered to tests under services/
c3_search(query='token bucket', path='services/**', kind='test')

Called with only file_path, this is the map tool: one line per symbol with its signature and [La-Lb] range, at roughly 10% of the file's tokens (services/file_map.py). Since 2.123.0 a directory path maps its files instead: one line per file with up to six of its top symbols, most-recently-edited first, capped at 400 files. Pass symbols or lines to read exact source. c3_compress left the MCP surface in 2.124.0 (six modes collapsed into one canonical map, since telemetry showed almost nothing used the other five); this tool is the only map entry point now, and it already accepts a comma-separated file_path for a batch. A file whose map would cost more tokens than its source (small files) is served whole instead, headed whole file — smaller than its map. A very large file (2 MB+) is not parsed at all. Read it with lines=[a,b]. Paths outside the project root are read too (tagged [c3-read:external]), for a sibling repo or an extra working directory.

Examples

# Map a file (no symbols/lines)
c3_read(file_path='cli/mcp_server.py')

# Map a directory — one line per file
c3_read(file_path='services/')

# Read specific symbols
c3_read(file_path='services/session_manager.py', symbols=['SessionManager.save', 'SessionManager.restore'])

# Read by line range (from the map's [La-Lb])
c3_read(file_path='cli/c3.py', lines=[660, 720])

# Map a batch of files in one call
c3_read(file_path='services/memory.py,services/agents.py')

Filters noisy terminal output, log files, or JSONL data to return only relevant lines. Use whenever command output exceeds ~10 lines. Supports inline text or file path input.

Examples

# Filter inline terminal output
c3_filter(text="<pytest output with 200+ lines>")

# Filter a log file for errors
c3_filter(file_path=".c3/sessions/session_042.json", pattern="error|fail")

# Filter build output
c3_filter(text="<webpack build output>", pattern="warning|error")

The only way to edit files in C3. Validates the old_string match, applies the patch, writes the file, and logs the change to the edit ledger. Supports single edits and batched edits to the same file. Can be called in parallel for different files.

Single edit

c3_edit(
  file_path='services/auth.py',
  old_string='return token.expiry > now',
  new_string='return token.expiry > now + CLOCK_SKEW',
  summary='Add clock skew buffer to token expiry'
)

Batch edits to same file

c3_edit(
  file_path='core/config.py',
  edits=[
    {"old_string": "DEBUG = True",      "new_string": "DEBUG = False"},
    {"old_string": "LOG_LEVEL = 'DEBUG'", "new_string": "LOG_LEVEL = 'WARNING'"}
  ],
  summary='Production config hardening'
)

Runs the appropriate native syntax checker for each file type. Supports comma-separated batch validation. Always call after c3_edit and before reporting done. If pyright (Python) or tsc (TypeScript) is on PATH, also runs a deep type check and reports type errors as advisory warnings alongside the PASS result.

Examples

# Single file
c3_validate(file_path='services/memory.py')

# Batch (runs in parallel)
c3_validate(file_path='cli/c3.py,cli/mcp_server.py,services/agents.py')

Supported file types

Finds every file that references a symbol (function, class, variable) before you rename or remove it. Uses git grep for speed with a pure-Python fallback. Groups results by file, scores risk (SAFE / LOW / MEDIUM / HIGH), and in unstaged mode overlays which affected files have uncommitted changes.

Examples

# Check blast radius before renaming a function
c3_impact(target='handle_memory', file_path='cli/tools/memory.py')

# Which affected files also have uncommitted changes?
c3_impact(target='MemoryStore', mode='unstaged')

# Safe to remove? (check before deleting)
c3_impact(target='_legacy_scan')

Risk levels

Run a shell command through C3 with structured returns (exit_code, stdout, stderr, duration_ms), a hard timeout with tree-kill (taskkill /F /T on Windows), and automatic edit-ledger entries for git-mutating commands. Use for tests, git, builds, and one-shot scripts. The response never exceeds an 18 KiB budget (22 KiB ceiling; max_bytes may only lower it). Under budget the output is complete: ANSI/control sequences are stripped, \r progress rewrites collapse to their final state, and 3+ identical consecutive lines fold to one plus  [x N]. Over budget, a recognised test/build runner (pytest, unittest, cargo, tsc, jest, vitest) keeps its failure blocks, error lines and totals first (each announced by [La-b: why]), then a bounded head/tail; everything dropped is kept in a spill store outside the project for 3 days and named by an output_id in the header. filter_output=False skips only the two collapses (escapes are still stripped, the cap is never lifted). Native Bash remains the fallback for interactive / TTY commands (gh pr create with an editor, ollama run). Work that outlives one tool call belongs in c3_shell_job — a c3_shell timeout is never converted into a job.

Examples

# Run tests — exit_code propagates, failure blocks kept first over budget
c3_shell(cmd='pytest tests/test_c3_shell.py -v')

# Git mutation — affected files auto-recorded in the edit ledger
c3_shell(cmd='git commit -m "wire c3_shell"')

# Build with a longer timeout
c3_shell(cmd='npm run build', timeout=300)

# Use a vault secret without it ever entering context
c3_shell(cmd='npm publish', env_creds='NPM_TOKEN')

# Page back the rest of a clipped response
c3_shell(output_id='o-3f9a1c2b4d5e', output_action='search', pattern='FAILED')

# Portable JSON formatting — Git Bash may not include jq
c3_shell(cmd='curl -s http://localhost:8000/health | python -m json.tool')

Safety classification

The blocklist is a best-effort guard against the most catastrophic commands — not a sandbox. c3_shell runs arbitrary commands by design; for an intentionally dangerous command, use native Bash with explicit approval.

Full test suites, long builds, device/emulator commands: anything over the client's ~2 minute ceiling on c3_shell. start runs c3_shell's full pre-flight (blocklist, Access Guard cwd deny, advisory read scan, write scan with confirm holds, credential expansion) and then hands the command to a detached supervisor process that survives the MCP server, replying with a job_id='j-…' immediately; nothing here waits on the job, and a c3_shell timeout is never turned into one. Output lands in the same spill store as c3_shell and is always promoted there (a job's output is the deliverable), kept 3 days: page it with c3_shell(output_id=…, output_action=…). Jobs are per project AND per session — another project or session gets "not found". Not proxied through c3_project. Prefer c3_ci for this repository's own GitHub Actions workflows; jobs are for everything else.

Examples

# Kick off the full suite, get a job id back at once
c3_shell_job(action='start', cmd='pytest -q', timeout=1800)

# Check on it
c3_shell_job(action='status', job_id='j-3f9a1c2b4d5e')

# Watch the growing output while it runs
c3_shell_job(action='tail', job_id='j-3f9a1c2b4d5e', stream='stdout', lines='80')

# After it finishes, page the kept output by output_id from status
c3_shell(output_id='o-…', output_action='read', lines='1-200')

# All this project + session's jobs
c3_shell_job(action='list')

Reads .github/workflows/*.yml as the only source of truth; there is no second CI config. inspect shows the job DAG and what's runnable on this host; run executes in dependency order and SKIPS (never passes) a job whose dependency failed; rerun retries only what failed; failures returns structured {file, line, message} instead of raw logs. Only FULL_CI_PASS means every job ran here and passed — the only verdict that means safe to push. PARTIAL_PASS means something did not run (another OS, an action C3 can't execute, or a subset you selected) and is not a green light. Full action reference and the native/act engine choice live on the CI guide.

Actions

Examples

# See the job DAG and what's runnable here
c3_ci(action='inspect')

# Run everything this change could have broken
c3_ci(action='run', mode='required')

# One job
c3_ci(action='run', job='test (ubuntu-latest, 3.12)')

# Fix loop — only the failures
c3_ci(action='rerun')
c3_ci(action='failures')

Guards answer "may the agent touch this?"; locks answer "is someone already touching it?" Two sessions each run their own c3-mcp server, so two agents could interleave read → replace → write on the same file with no error on either side. c3_edit already takes a lease on the file it edits, carrying the intent from your edit summary; use acquire to claim a multi-file refactor up front. Acquisition is all-or-nothing over the path list, so two agents grabbing the same pair in opposite order cannot deadlock. TTL is the real release mechanism: a crashed agent's lease expires on its own (default 900s / 15min, locks.default_ttl_s in .c3/config.json) rather than wedging the repo; a lease you no longer need should still be released explicitly. Leases gate C3's own tool surfaces only — a raw shell redirect, a non-Claude agent, or a human in an editor is not covered. Set locks.enabled: false to opt out.

Examples

# Who holds what right now
c3_locks(action='list')

# Claim a multi-file refactor up front
c3_locks(action='acquire', paths='services/router.py,services/retry.py', intent='refactor retry backoff')

# Release when done
c3_locks(action='release', paths='services/router.py,services/retry.py')

# Drop expired leases (also happens automatically)
c3_locks(action='sweep')

When a call is refused with [c3-access:confirm] (a path the user set to "ask me first", or the builtin agent-config confirm tier), the refusal names a request C3 already filed, or the surface that files one. A yes from the user mints a single-use, session-bound, path-exact grant with a short TTL; the rule that blocked you stays in force. Most denials are not escalatable (credential vault, Tier-0, catastrophic shell commands) and are refused here without ever reaching the user. If a refusal did not invite you to ask, do not ask — mark the step blocked and tell the user instead. Full flow and the confirm-hold model live on the Access guide.

Examples

# A hold names a request id already filed — wait on it
c3_override(action='wait', request_id='req_a1b2c3', timeout_s=180)

# Nothing was filed — ask for this exact path yourself
c3_override(action='request', path='.env.production', why='need the DB host to reproduce the bug')

# What's still open
c3_override(action='list')

Manages the session lifecycle: log for decisions, snapshot before /clear, restore to recover after /clear, compact for a one-step restart. Since v2.143.0 it also covers the session catalog (one row per Claude Code conversation joining transcript, C3 sessions, decisions, snapshots and tasks), so you can find an old session, see what it was, and mark one a dead end. The full catalog, the Hub Sessions tab and resume flow are on the Sessions guide.

Actions

Examples

# Log a decision
c3_session(action='log', data='Chose Redis over memcached — TTL support needed', reasoning='Session persistence required')

# Before /clear
c3_session(action='snapshot')

# Before stopping — what got done, what's next
c3_session(action='note', data='Wired c3_shell byte budget', reasoning='Still need output_id paging tests')

# This session superseded an earlier dead end
c3_session(action='stale', target='a1b2c3d4', reasoning='restarted after a bad approach', data='current')

# One-step restart
c3_session(action='compact')

Persistent key-fact store that survives /clear and session restarts. Use recall at session start to recover context. Facts are stored with salience scores and auto-decayed over time. Supports semantic recall, explicit query, and manual management.

Actions

Examples

# Session start — recall relevant facts
c3_memory(action='recall', query='authentication token system', top_k=5)

# Large store: browse compact, then fetch just what you need
c3_memory(action='index')
c3_memory(action='fetch', fact_id='a1b2c3,d4e5f6')

# Add a new fact
c3_memory(action='add', fact='[architecture] JWT tokens use RS256 — public key in /etc/c3/jwt.pub', category='architecture')

# Save a convention
c3_memory(action='add', fact='[convention] All new API handlers must call audit_log() before returning', category='convention')

# Verify facts are still accurate
c3_memory(action='ground')

# List all architecture facts
c3_memory(action='list', category='architecture')

Project and session status dashboard. Check token budget, server health, pending notifications, and active session summary.

Examples

c3_status(view='budget')           # Token budget remaining
c3_status(view='health')           # Memory / index / notification health
c3_status(view='notifications')    # Pending alerts (budget warnings, etc.)
c3_status(view='access')           # Current Access Guard rules

Sends a bounded task (summarize a diff or log, explain a function, triage a traceback, draft a docstring or test cases) to a smaller model from the provider you already run on. In Claude Code that is Haiku by default, through a tool-less claude -p that answers only from the context C3 packs for it. On C3's delegate eval, Haiku passed all 22 bounded cases at about a fifth of Opus's cost.

Examples

# Summarize a diff on Haiku (Claude Code host, default tier)
c3_delegate(task='Summarize this diff for a changelog in three bullets', context='<diff>', task_type='summarize')

# Explain a function on Sonnet
c3_delegate(task='What does resolve_host return inside a grok child?', file_path='core/host.py', task_type='explain', tier='medium')

# A lookup the delegate does itself
c3_delegate(task='Which functions call charge_card, and where?', scout=True)

# A change you have decided, made by Sonnet inside a write set
c3_delegate(task='Rename calc_total to order_total in its definition and every use; no alias', write_paths='inv/orders.py, inv/report.py, tests/test_orders.py')

Executes compound multi-step workflows using multiple C3 tools in sequence. Useful for common patterns like reviewing changes, preparing context, or running a preflight check.

Available workflows

Examples

# Run a preflight before starting work
c3_agent(workflow='preflight', context='starting auth refactor')

# Prepare context for a specific area
c3_agent(workflow='prepare_context', scope='services/memory.py,services/agents.py')

# Review what changed recently
c3_agent(workflow='review_changes')

# Deep investigation
c3_agent(workflow='investigate', context='why does session restore fail after compact?')

Access the edit ledger — a persistent append-only log of all file changes made through c3_edit. Provides history, version diffing, stats, and tagging. The ledger is also enriched in the background by the EditLedgerEnricherAgent. Since v2.35.0, each entry is stamped with the git branch and HEAD it was made on, and history can be filtered by branch.

Actions

Examples

# Show recent edit history
c3_edits(action='history')

# Version history for a specific file
c3_edits(action='versions', file='services/memory.py')

# Ledger stats
c3_edits(action='stats')

# Edits made on a specific branch
c3_edits(action='history', branch='feature/x')

# c3_edit errored or timed out — did it actually write?
c3_edits(action='verify', file='services/router.py',
         old_string='RETRY_LIMIT = 3', new_string='RETRY_LIMIT = 5')

Every C3 project carries a PM store at .c3/pm/pm.json: tasks with status (backlog / in_progress / blocked / done), priority (p0–p3), due dates, tags, and code links (files, commits, edit-ledger entries, sessions); milestones with computed progress; a time log; and a decision-note log separate from AI memory. The same store powers the Hub's Tasks tab and kanban board, the per-project UI's Tasks tab, and this tool. Task ids accept any unique prefix (≥4 chars); milestones resolve by id or unique name. Read actions are plan-mode-safe. Ephemeral session plans stay in c3_session(action='plan').

Actions

Examples

# Capture a task while coding
c3_task(action='add', title='Harden pm.json against concurrent writes',
        priority='p1', tags='pm,backend')

# Tie it to the code it touches, then finish it
c3_task(action='link', task_id='a1b2c3d4', link_type='file', ref='services/task_store.py')
c3_task(action='done', task_id='a1b2')

# Milestones + the board
c3_task(action='milestone_add', name='v2.46', target_date='2026-08-01')
c3_task(action='board')

# Ship it — tasks keep their link, unlike archive
c3_task(action='milestone_complete', milestone='v2.46')

# Log time against a task
c3_task(action='time_add', minutes=45, task_id='a1b2', note='wrote the migration')

# Record a decision
c3_task(action='note_add', note='Kanban rank uses float sort keys', kind='decision')

Surfaces: the Hub shows a Tasks tab per project (drill-in panel), ☑ N open-task chips on cards, and a global kanban board behind the Projects | Tasks switcher. Hub mutations audit pm_write events to the project's activity log. Disable with hybrid.pm.enabled=false.

C3 tracks every agent-affecting artifact across all IDEs it knows: instruction docs (CLAUDE.md, AGENTS.md, GEMINI.md, .cursorrules, .github/copilot-instructions.md), settings/hooks (.claude/settings*.json), MCP configs (.mcp.json, .codex/config.toml, .gemini/settings.json, …), and Claude Code extensions (.claude/ skills, agents, commands, plugins). Content-addressed snapshots land in .c3/agent_artifacts/; every change is a history event with attribution: c3_edit (this session), hook (native Edit/Write), scan (out-of-band — you edited it in an editor), install_mcp (C3 regenerating its own files), or restore. A background agent scans every ~2 min and warns only when settings or MCP configs change outside C3. Artifact refs accept an id (skill:browcontrol), unique prefix, or plain path (CLAUDE.md). Everything except restore is plan-mode-safe.

Actions

Examples

# What changed behind my back?
c3_artifacts(action='status')
c3_artifacts(action='history', limit=10)

# Someone (or something) touched the hooks — inspect and roll back
c3_artifacts(action='diff', artifact='.claude/settings.local.json', version=3)
c3_artifacts(action='restore', artifact='settings:.claude/settings.local.json', version=3)

# Track a skill's evolution
c3_artifacts(action='history', artifact='skill:browcontrol')
c3_artifacts(action='show', artifact='skill:browcontrol', version=2)

Surfaces: the Hub drill-in panel gets an Artifacts tab (class-grouped inventory, per-version timeline, diff viewer, two-step restore); REST at /api/artifacts* per project and /api/projects/artifacts* on the hub. Changes made through c3_edit and install-mcp self-attribute — only genuinely foreign edits show as scan. Disable with hybrid.agent_artifacts.enabled=false.

Connect to a self-hosted enterprise Bitbucket server and operate on it. Tokens live in the OS keyring (Windows Credential Manager / macOS Keychain / Linux Secret Service); only a non-secret index of accounts and the active-account pointer is written to .c3/config.json. Project key + repo slug fall back to the configured defaults.

Setup: c3 bitbucket login --url <URL> (interactive PAT prompt), then c3 bitbucket set-default --project PROJ --repo my-repo. See the Bitbucket integration guide for the full action reference, Hub UI tour, audit-trail integration, and troubleshooting.

Actions

Examples

# Connection probe + active account info
c3_bitbucket(action='status')

# List open PRs in the default repo
c3_bitbucket(action='list_prs', state='OPEN')

# Open a PR
c3_bitbucket(action='create_pr',
             title='Add Bitbucket integration',
             from_branch='feat/bitbucket',
             to_branch='main',
             reviewers='alice,bob')

# Approve and merge — version is fetched automatically
c3_bitbucket(action='approve_pr', pr_id=42)
c3_bitbucket(action='merge_pr', pr_id=42)

Audit trail: mutating actions (merge_pr, create_branch, delete_branch, webhook writes, etc.) are appended to the C3 edit ledger so the local audit log covers platform-side state changes too.

A user-managed secret store, global (~/.c3, visible in every project) or per-project (.c3, shadows the same-named global). Values live in the OS keyring (service c3-creds; values over ~1KB in a Fernet-encrypted .c3/secrets.enc whose random master key is itself a keyring entry), never in config files, and never in the model's context. Injection-first: the agent addresses secrets by name and C3 decodes them only at the subprocess boundary — c3_shell(env_creds='A,B') injects env vars, {{cred:NAME}} inside cmd expands server-side, and inject-flagged entries auto-inject into every shell run; echoed values are redacted back to [cred:NAME]. Resolution is realm-atomic: a project-registered name resolves in the project realm or not at all, so a hostile repo's committed config can never siphon your global values (tested).

Actions

Structured kinds

v2.87.0 added address/identity/card, v2.90.0 added login. These hold named fields (card: cardholder/number/expiry[/cvc/billing_zip]; login: site_id/canonical_target/username[/password/private_key/…]) and are inject-only: address a single field with env_creds='CARD.number' or {{cred:CARD.number}}; reveal is disabled and they never auto-inject. login (v2.118.0) covers servers and databases too, not just websites: canonical_target is scheme://host[:port] from an allowlist (https, ssh, sftp, postgres, mysql, redis, …). It is storage only — C3 opens no session and types nothing anywhere; have the user enter values through the Credentials UI or c3 creds set so they never enter the chat.

Examples

# What can I use? (names and metadata only)
c3_credentials(action='list')
c3_credentials(action='check', name='NPM_TOKEN')

# USE a secret without ever seeing it
c3_shell(cmd='npm publish', env_creds='NPM_TOKEN')
c3_shell(cmd='curl -H "Authorization: Bearer {{cred:API_KEY}}" https://api.example.com')

# Preview a .env import, then commit it
c3_credentials(action='import_env', file_path='.env.production')
c3_credentials(action='import_env', file_path='.env.production', dry_run=False)

Surfaces: the c3 creds CLI (set / get / list / rm / import .env, --global for the shared scope), a per-project dashboard Credentials tab, and a top-level Credentials view in the Hub (v2.59.0) managing the global vault and every registered project, with overriding shown both ways. Since v2.61.0 that view adds cross-project search (/ or Ctrl/⌘-K; project: scope: inject: agent: shadow: qualifiers, results grouped by credential name), a per-credential settings drawer (metadata, exposure switches, resolution check, write-only value replacement, usage & overrides, delete), and a right-click context menu; destructive and exposure-raising actions require typing the credential name. No HTTP route ever returns a stored value (write-only wire contract, endpoint-sweep tested), every mutation is ledger-logged by name, the vault is hard-excluded from the Oracle Discovery API, and cross-project (c3_project) shells run with credentials disabled.

See the credential vault guide for storage internals, the scope/override model, injection paths, exposure-flag semantics, the Hub UI tour, search qualifiers, and troubleshooting.

One tool for both Jira deployments: Cloud (REST v3, email + API token, ADF bodies handled transparently) and self-hosted Data Center / Server (REST v2, PAT Bearer, plain-text bodies) — normalized to a single DTO surface with an opaque pagination cursor. Transport is stdlib urllib (no new dependencies); reads get one bounded 429 retry honoring Retry-After, mutations are never auto-retried. Tokens live in the OS keyring keyed by (base_url, username); the jira config section resolves project → home wholesale from a single file, so a repository's committed config can never field-override a home account's URL or TLS settings (credential-redirect hardening). HTTPS-only.

Setup: c3 jira login --url https://yoursite.atlassian.net (Cloud inferred for *.atlassian.net; add --deployment data_center for self-hosted, --ca-bundle for enterprise certs, --global for a home config reusable across projects), then c3 jira set-default --project PROJ. Manage accounts with c3 jira status / use / logout.

Actions

Examples

# Connection + account probe, then my open work
c3_jira(action='status')
c3_jira(action='my_issues')

# Raw JQL search
c3_jira(action='search', jql='project = PROJ AND status != Done ORDER BY updated DESC')

# Create — required fields come from metadata, not guesses
c3_jira(action='get_create_metadata', project='PROJ', issue_type='Task')
c3_jira(action='create_issue', project='PROJ', issue_type='Task',
        summary='Fix login flow', description='Steps in thread')

# Field rejected on create ("not on the appropriate screen")? Set it post-create
c3_jira(action='update_issue', issue='PROJ-124', fields='{"customfield_10014": "PROJ-42"}')

# Put an issue under an epic — no customfield hunting (Cloud parent field
# vs Data Center Epic Link customfield is resolved for you)
c3_jira(action='update_issue', issue='PROJ-124', parent='PROJ-42')

# Typed links: reads "PROJ-1 blocks PROJ-2"
c3_jira(action='link_issues', issue='PROJ-1', link_type='blocks', target='PROJ-2')

# Sprint flow: board -> sprint -> assign
c3_jira(action='list_boards')
c3_jira(action='list_sprints', board_id=7, sprint_state='active')
c3_jira(action='move_to_sprint', issue='PROJ-1, PROJ-2', sprint_id=42)

# Time + evidence
c3_jira(action='add_worklog', issue='PROJ-1', time_spent='2h 30m', body='pairing')
c3_jira(action='attach_file', issue='PROJ-1', file_path='logs/build.log')

# Move it along — id or name both work
c3_jira(action='list_transitions', issue='PROJ-123')
c3_jira(action='transition', issue='PROJ-123', transition='In Progress')
c3_jira(action='comment', issue='PROJ-123', body='Deployed to staging')

Surfaces & audit: the per-project dashboard gets a Jira tab (My Work board grouped by statusCategory, JQL search, an issue drawer with transition buttons + comments, and an Activity view) backed by /api/jira/* routes. Issue keys like PROJ-123 are auto-linked from branch names and edit-ledger entries (acronym denylist, so UTF-8 / SHA-256 / CVE-2024 never match), and the issue drawer shows the local ledger activity for the open issue; that Activity view works with no account configured. Mutations (create_issue, update_issue, comment, transition, assign, link_issues, unlink_issues, move_to_sprint, move_to_backlog, add_worklog, attach_file, delete_issue) are edit-ledger-logged with identifiers only — bodies are never logged. Read actions are safe in plan mode.

Reach outside the current workspace. C3 keeps a global registry of installed projects (~/.c3/projects.json); c3_project lists/scans them and proxies the core C3 operations against any one — building and caching a full runtime per target project on demand. Name the target by registered name or absolute path (a .c3 directory is required).

Write safety: read ops run freely; mutating ops (edit, shell, and memory add/update/delete) are refused unless you pass allow_write=true, and every foreign mutation is recorded on the target project's activity log and edit ledger.

Actions

Sub-project hierarchy: project is the PARENT. A child need not live inside it: sub_link takes an absolute path anywhere on disk, including another drive, and hierarchies nest up to 8 levels. Nested children are excluded from the parent's index; externally linked ones were never in it. Linking is refused if it would make a project its own ancestor.

Examples

# Which projects have C3 installed?
c3_project(action='list')
c3_project(action='scan')              # also finds unregistered .c3 dirs nearby

# Search / read inside another project
c3_project(action='search', project='SafeMirror', query='token bucket')
c3_project(action='read', project='SafeMirror', file_path='core/limiter.py', symbols='RateLimiter')

# Memory recall from another project's fact store
c3_project(action='memory', project='Sentinel', mem_action='recall', query='auth flow')

# Guarded write — the edit lands in the target project's ledger
c3_project(action='edit', project='Sentinel',
           file_path='README.md',
           old_string='v1', new_string='v2',
           allow_write=true)

# What is at this path, and who already claims it? (read-only)
c3_project(action='sub_inspect', project='Code Context Control',
           target=r'U:\1. Projects\Claude Code Companion (C3)\c3-mobile')

# Link it — a sibling on disk, not nested, so containment cannot express it
c3_project(action='sub_link', project='Code Context Control',
           target=r'U:\1. Projects\Claude Code Companion (C3)\c3-mobile',
           allow_write=true)

c3_project(action='sub_tree', project='Code Context Control')   # every level

Sub-action params: search_action (code/files/semantic/…), mem_action (recall/index/fetch/add/…), and edits_action (history/versions/stats) pick the operation for those verbs; scan_roots (comma-separated) overrides where scan looks.