Loading repository data…
Loading repository data…
sshoecraft / repository
Self-contained Claude Code env: bundled MCP servers (ccmemory, ccusage, ccteam), project awareness skill (ccproject), and a relay-loop wrapper (ccloop), with an overlay system for per-user / per-host extensions.
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
The missing operating environment for Claude Code.
Claude Code is an excellent coding agent, but it has no long-term memory, no continuity between sessions, no awareness of previous work, and no built-in way to coordinate multiple instances.
ccenv fills those gaps.
It layers project awareness, persistent memory, prospective memory, automatic session handoff, context monitoring, and multi-agent coordination on top of Claude Code while remaining lightweight and composable.
The result is a continuous AI development environment where work survives context exhaustion, sessions resume with minimal friction, and long-running projects can evolve across days, weeks, or months instead of ending when a conversation does.
| Component | What it does | MCP name |
|---|---|---|
ccproject | Three-layer project awareness skill (constitution → subsystem docs → structural map) + global ~/.claude/CLAUDE.md snippet | — |
ccmemory | Persistent file-backed memory with FTS5 index, autoinstalled hooks, MCP server | ccmemory |
ccprospect | Prospective memory: immutable intention/forecast contracts with typed predicates, evaluated at wake boundaries into an inbox; autoinstalled hooks, MCP server | ccprospect |
ccusage | Real-time context-window + rate-limit usage as an MCP tool and statusline | ccusage |
ccloop | Relay-loop wrapper that hands work between fresh Claude Code sessions as context fills | — |
ccteam | Multi-instance coordination layer (filesystem replication via NATS JetStream, file-level locking, MCP tools + hooks) | ccteam |
Each component still lives in its own subdirectory and has its own
README.md, pyproject.toml, and tests. Top-level install.sh
delegates to each component's own installer where one exists, and falls
back to pip3 install --user <path> (non-editable) for the rest.
git clone https://github.com/sshoecraft/ccenv.git
cd ccenv
./install.sh
Per-component options:
./install.sh --skip ccteam # skip a component (repeatable)
./install.sh --only ccmemory # install only listed components (repeatable)
./install.sh --no-overlays # skip the overlay scan
./install.sh -h # full help
Re-running is idempotent. Each sub-installer checks its own state; MCP
registrations use claude mcp get <name> to detect prior installs;
~/.claude/CLAUDE.md overlay blocks are stripped and re-applied so stale
content self-heals.
install.sh scans three locations for per-user / per-host extensions
that should layer on top of the bundled components:
/usr/local/ccenv — system-wide overlay
~/.config/ccenv — per-user overlay
<this script's dir> — bundled (only scanned for MCP subdirs, not CLAUDE.md)
In an overlay directory, the installer looks for:
CLAUDE.md — appended to ~/.claude/CLAUDE.md inside a
# [CCENV OVERLAY: <path>] … # [/CCENV OVERLAY: <path>] marker
block. Re-runs strip stale blocks and re-merge eligible ones.
(System and user dirs only — never the bundled dir.)
<subdir>/pyproject.toml — pip-installed (--user) and registered
as a user-scope MCP server. Default registration: name and command both
default to the subdir name. Override with <subdir>/.ccenv-mcp.json:
{"name": "myname", "command": "bin", "args": ["--flag"], "scope": "user"}
This lets you add custom MCP servers on a single laptop, or distribute
them via /usr/local/ccenv on a shared box, without touching the bundled
component tree.
All MCP servers register at user scope under a cc<short> convention:
ccmemory, ccusage, ccteam. Overlay MCP servers default to their
subdir name unless overridden.
pip3PATH for MCP / hook registration steps (the
installer falls back gracefully and prints warnings if it can't find
claude)nats-server with JetStream — only if you want ccteam's
cross-instance coordination. Without it, ccteam boots in standalone
mode and a SessionStart hook surfaces a one-line notice in any
.ccteam/-bootstrapped project so you know sync is off.MIT — see LICENSE.