Claude Code Projects: Always‑On Conversation, New Team Risks

Anthropic’s Claude Code Projects hit the Google Trends technology feed on 2026-09-17 as an “always-on conversation” that “remembers and delegates” long-running development work. The keyword people are searching is basically a mouthful: claude code projects always on conversation.

This feature matters because it changes the unit of work from “a chat session” to “a persistent workspace.” If you’re running agentic coding teams, that flips your day-to-day from prompting to operations. Memory scope, secrets retention, auditability, and cost drift stop being theoretical. They become your next incident.

What is Claude Code Projects?

Claude Code Projects is a persistent Claude Code workspace where an “always-on conversation” keeps long-running development context around so you can resume, delegate, and continue work across days instead of restarting from a fresh session.

The important mental model: Projects are state. State is power. State is also risk.

Here’s a quick “verify in your own setup” checklist I’d use before I let this anywhere near a production repo:

• Is the Project scoped to a single repo checkout, a folder path, or can it span multiple repos?
• What exactly persists: messages, tool call history, file summaries, task lists, decision notes?
• What is the retention window and deletion story?
• Is memory shared across a team, or per-user?
• Can admins export the Project history for audit?

Anthropic hasn’t published enough first-party detail in the sources we can reliably fetch today, so I’m treating Projects as “persistent context” and focusing on what engineering leaders need to lock down on day 0.

Projects vs a normal Claude Code session (at a glance)

That last row is the sleeper issue. Always-on context tends to turn token usage into a slow leak.

The problem: your AI knows more than your codebase

Nishikanta Ray (open-source maintainer of Attic) describes the real pain bluntly: without persistence, teams “pay for the same investigation twice.” I’ve watched this happen even in my own workflow building this site’s multi-agent publishing pipeline. Deterministic gates catch issues early, but when an agent loses context mid-flight, you burn tokens and time re-deriving decisions that should have been recorded once.

Ray’s core observation is the one Claude Code Projects is trying to productize: codebases don’t preserve reasoning. They preserve outcomes.

You can merge the fix, but you lose:

• Why a particular code path is “weird but correct”
• Which directories are generated garbage
• Which tests are flaky and why
• Which environment variable names matter

That’s exactly the stuff humans carry in their heads and in Slack threads. Projects attempts to keep it with the agent.

The catch: memory is not truth. It’s an artifact. It can go stale, it can be poisoned, and it can leak.

Why not just put everything in the system prompt?

Because it’s the same mistake as shoving your entire architecture doc into a single README.md and calling it “documentation.” It feels productive until it isn’t.

Ray points out the operational problem: bloating the system prompt (or any always-injected context) makes the model carry irrelevant baggage for every task. That means higher cost, more distraction, and more chances the model latches onto outdated assumptions.

A persistent Project should not become one giant, ever-growing prompt.

If you’re already doing RAG or retrieval-augmented generation, you already know the pattern. Keep the “always-on” layer small and retrieval-friendly.

The four commands: put knowledge in, get knowledge out

Ray’s Attic design uses four verbs that are basically the right abstraction for any persistent dev memory system:

1. Capture a discovery when it’s fresh
2. Index it so you can find it later
3. Recall it only when it’s relevant
4. Update it when reality changes

Projects will inevitably implement some version of this, even if the UI looks different.

If you don’t have explicit verbs, your “memory” becomes an unstructured chat log. That’s not memory. That’s a landfill.

The part I find most interesting: the index is not the memory

This is the piece most teams will miss.

Ray separates a small INDEX.md (retrieval surface) from the detailed stored notes (the actual memory). The index is what you search. The memory is what you inject.

That separation is how you avoid cost drift and hallucinated overreach:

• The index stays small enough to keep around.
• Detailed notes get pulled in only when the task matches.

If you’re building internal agent memory, treat this like designing a production search system. A good index is a product.

If you want a deeper mental model for memory + retrieval tradeoffs, my longer write-up on AI agents and agent orchestration is the backbone.

How team delegation should work in an always-on Project

Projects makes “handoff” a first-class feature. That’s the upside.

The downside is merge-conflict-by-default. Two humans editing the same file at once is already messy. Two agents editing overlapping surfaces across hours, with persistent assumptions, is worse.

Here’s the delegation model I’d actually trust:

• One Project, one owning PR. No “drive-by” changes without a branch and PR anchor.
• Task decomposition is explicit. The Project should maintain a living task list with IDs that map to tickets.
• Independent verification is required. The agent that wrote the code does not “approve” the code. Use a second pass: tests, linters, a separate agent, or a human reviewer.

I’ve shipped enough workflow automation to know that systems fail at boundaries, not in the happy path. Projects creates a new boundary: between “what the agent remembers” and “what the repo actually is today.”

If you want a concrete review flow, start with my review AI-generated code checklist and the bigger workflow policy in AI in production.

Repo boundary gotchas (monorepos, submodules, generated code)

Persistent memory forces you to define what “the project” even is.

In a monorepo, the agent will happily learn that “package X depends on package Y” and apply it across the entire tree. Then someone refactors the dependency graph, and your always-on Project becomes confidently wrong.

What I’d standardize:

• Monorepo: define a Project per “bounded context” (service/package), not per repo. If your repo has 40 packages, you don’t want one memory blob spanning all 40.
• Multi-repo services: don’t let memory cross repos unless you have a real reason. Cross-repo memory is a secret-sharing mechanism in disguise.
• Submodules: treat them as external dependencies. Don’t let the Project write into them by default.
• Generated artifacts: explicitly deny listing/editing dist/, build/, codegen output, and vendored deps. Otherwise the agent will burn cycles, tokens, and possibly commit noise.

This is the same idea as microservices boundaries. Memory needs boundaries too.

Security and governance: permission modes, sandboxes, secrets, and audit logs

Persistent context increases the blast radius of two classic failures: tool misuse and secrets leaks.

jsmanifest’s security breakdown is the right starting point: permission modes and sandbox boundaries are different layers. Permission modes decide whether Claude attempts an action. Sandboxes decide what that action can touch even if it’s allowed.

If you’re running Projects for weeks, this separation matters more, not less.

The Four Permission Modes: Auto, Prompt, Restricted, and Custom

From jsmanifest’s write-up:

• Auto: the model acts without asking. Fast. High-risk.
• Prompt: asks before actions. Safer, but humans rubber-stamp.
• Restricted: denies tool calls by default.
• Custom: whitelist what you mean, deny the rest.

For Projects, my stance is blunt: Auto mode should not be your team default. Not for anything touching production credentials or deploy paths.

If you want speed, put speed into better scaffolding and defaults, not into “the agent can run anything.” This is the same lesson I learned building SOC 2 scaffolding CLI tooling at Rise People. Compliance baked into scaffolding beats compliance review at PR time.

Understanding `--allowedTools` and whitelisting specific capabilities

jsmanifest also calls out the trap: --allowedTools can stop invocation of forbidden tools, but it does not restrict what the allowed tools can access.

If you allow run_command and your sandbox can see your whole filesystem, you didn’t build guardrails. You built a polite warning.

Treat whitelists as capability gating, not data access control.

Sandbox boundaries: what bubblewrap and Seatbelt actually restrict

On Linux/macOS, sandboxing (bubblewrap/Seatbelt) is what defines the outer boundary of damage. If the agent can only see a working directory with a read-only mount of the repo, you just eliminated a whole class of “oops.”

This is also where local LLM setups can be safer for some teams. You get tighter control over data egress. You also inherit new ops burden.

Defense-in-depth: combine permission deny rules with sandbox restrictions

Defense-in-depth is not optional for persistent Projects.

My recommended baseline:

• Custom permission mode with explicit denies
• Tight sandbox boundary to a single repo folder
• Network egress blocked by default, allowlist only what’s needed (package registry, internal docs)
• Secret scanning on:
  • what the agent reads
  • what it writes
  • what it remembers

If you’re serious about this, pair it with a prompt-injection plan. Persistent memory is a huge target for prompt injection and broader AI security. A poisoned note that lives for 3 weeks is worse than a bad one-off answer.

Common misconfigurations when sandbox settings don’t match permission rules

The most common failure pattern is mismatched intent:

• You run Prompt mode, but the sandbox has full disk access.
• You run Restricted mode, but you allow one “escape hatch” tool that can do anything.
• You whitelist tools, but forget that allowed tools can touch secrets.

This is exactly how “we thought it was safe” incidents happen.

Secrets hygiene for persistent memory

Persistent Projects increases the chance that someone pastes a token once and it’s available forever.

Concrete mitigations that actually work:

• Use pre-commit + CI secret scanners (I like gitleaks). My setup guide: gitleaks + pre-commit + CI.
• Standardize direnv or environment-based secrets loading. Do not paste secrets into prompts. If you need a reminder, see Prevent API key leaks in shell history.
• Add redaction at the agent logging layer. I wrote a practical playbook on redact secrets.
• Treat Project memory like logs. Apply the same retention and deletion posture as you’d use for production logs. My broader policy view is in LLM data leakage.

Auditability: approvals, logs of tool calls, diffs, traceability

If Projects becomes “always-on,” your org will eventually be asked: who changed what, and why?

The minimal viable audit chain:

• Every agent action maps to a PR (branch name includes ticket ID)
• Tool calls are logged with timestamps and working directory
• File diffs are attached to the PR (not hidden in chat)
• Approvals are recorded (human-in-the-loop patterns help: HITL tool approval patterns)

If you want an observability-first approach, start with AI agent observability logging schema and OpenTelemetry instrumentation for AI agents.

Cost drift and failure modes unique to persistent memory

Always-on context has a financial smell. It’s “just a little more” every turn.

Based on benchmark work I’ve published on this site, the overhead of agent harnesses can be non-trivial. In my own measurement write-up on AI in production, the point wasn’t a universal number. It was that orchestration layers add real cost beyond raw model tokens.

Projects adds another multiplier: retained context that keeps getting dragged forward.

What I’d implement as a cost hygiene policy:

• Budget per Project per week (hard cap or at least alerting)
• Compaction rules: after major milestones (PR merged), compact and extract an index entry
• Memory lifecycle: pin what’s durable (architecture decisions), prune what’s transient (debug logs), archive what’s done (closed incidents)
• Stop conditions: explicit “don’t keep searching” rules to avoid runaway loops

If your finance org wants numbers, point them at the live data I maintain at kunalganglani.com/llm-prices for current token costs. Per-token pricing is misleading without workload shape assumptions, but it’s the starting input.

Should project memory artifacts be committed to Git?

My stance:

• Commit the index if it’s human-readable, curated, and treated as documentation.
• Do not commit raw memory dumps, tool logs, or “conversation transcripts.” That’s where secrets and irrelevant noise end up.

This mirrors Ray’s index-vs-memory separation. It’s also the only way to keep your repo from turning into an agent scrapbook.

Failure modes that get worse with persistence

Persistent memory creates unique footguns:

• Stale assumptions: “we don’t use Redis” becomes wrong after a migration.
• Hallucinated facts that stick: a wrong note becomes a persistent dependency.
• Overfitting to old architecture: the agent keeps implementing the 2025 patterns in a 2026 refactor.
• Memory poisoning: an attacker slips instructions into remembered notes.

If you’ve ever debugged a production incident caused by an outdated runbook, you already understand the shape of the problem. Projects is basically “runbooks, but the agent reads them constantly.”

A quick practical reference: what Projects should remember vs not remember

What you want persisted:

• High-level architecture decisions with dates
• Directory allow/deny lists
• How to run tests and common failure fixes
• “Weird but correct” invariants

What you want aggressively excluded:

• Secrets (tokens, API keys, private certs)
• Raw logs, stack traces, customer data
• Full-file copies when a pointer would do

If you want to train your team on this, link them to AI security and AI security attack surface.

Here’s the official walkthrough that’s closest to “how real teams do it”:

Austin Marchese’s video is a useful look at operational prompting patterns in Claude Code.

The bigger point: prompting patterns become policies when you have always-on memory.

My prediction: by mid-2027, every serious engineering org using agentic coding will have a “memory SRE” function, even if they don’t call it that. Someone will own scope, retention, audit, and budgets for these Projects the same way we already own CI/CD and secrets.

If you’re adopting Claude Code Projects now, don’t wait for the first leaked token or surprise bill to force the conversation. Write the rules while the feature still feels new.

Photo by James Harrison on Unsplash.