Feature Request: Workspace / Context Isolation for Repositories

[GuzzoLM]

Problem

When working with multiple projects simultaneously, Supacode currently stores all repositories under a single flat structure:

~/.supacode/repos/<repo-name>

This creates a few challenges:

• No clear separation between different contexts (e.g. work, open source, side projects)
• Agents may miss project-specific context (e.g. agents.md)
• Harder to manage large numbers of repositories
• Increased cognitive load when switching between domains

---

Proposal

Introduce a Workspace (or Context) concept, where repositories and agent context are grouped under a shared environment.

Example structure:

~/.supacode/workspaces/<workspace-name>/
  repos/
  agents.md
  context.json

---

What a Workspace Would Represent

A workspace represents an execution context, including:

• A set of repositories
• Shared agents.md (or similar config)
• Optional context/state (e.g. tasks, environment assumptions)
• Logical grouping by purpose (e.g. work, oss, personal)

---

Example Use Cases

1. Work vs Personal Separation

• myCompany workspace → company repos, strict conventions
• myAmazingLibs workspace → some OSS project
• myBrandNewThing workspace → some side project

Each with its own:

• agent behavior
• assumptions
• context

---

2. Improved Agent Performance

By scoping context per workspace:

• Reduces irrelevant context passed to agents
• Avoids cross-project contamination
• Improves reasoning accuracy

---

3. Better Developer Experience

• Cleaner mental model
• Easier context switching
• Aligns with how developers actually work (project-based thinking)

---

Happy to Contribute

If this direction makes sense, I’d be happy to help iterate on the design or contribute to an implementation.

[sbertix]

Hey 👋

I definitely think this could be very useful. Only note is that I would possibly market this more as a "Profile" selection, like browsers do, since it implies much more than just a different workspace from what I can gather.

My concern is that this would require refactoring a lot of code. Could you share a more detailed PRD and some specs on how you would want this tackled? Things like migration (cause I don't see it working as just an extra layer, tbh, but I might be wrong), #101 and #188 + env (it'd be nice to have them fit here), etc.

[GuzzoLM]

Hi @sbertix! Thanks for the response!

On "Profile" vs "Workspace" framing, I agree. "Profile" makes more sense.

Migration path:
I think we could go this way: Profiles should be directories on disk (~/.supacode/profiles//), not just JSON entries. This keeps migration non-breaking.

• A default profile absorbs the current flat repo list, so zero change for users who don't adopt profiles.
• Repository.ID stays as the standardized file path, completely independent of which profile it belongs to.
• Settings resolution becomes a three-tier chain: global → per-profile → per-repo. The existing SettingsFile / @Shared(.repositorySettings) pattern already has clean separation, so per-profile config slots in naturally.
• Each profile being a directory on disk makes it extensible to future per-profile configuration files without schema changes.

About the issues you mentioned:

• Worktree base directory collisions when repositories share basename #101: Profiles don't touch repositoryDirectoryName() identity. But if path identity is being refactored for 101 anyway, designing both together avoids two migrations.
• Per Repo gh Authorisation Settings #188: Profiles address this at a higher level. A profile could carry environment variables (e.g., GH_CONFIG_DIR), so all repos under "work" use work credentials and "personal" uses personal ones. Per-repo overrides could still exist for edge cases.

Environment variables:
I suppose the profile directory could include config with an env dictionary. When Supacode spawns terminals or gh commands for repos in that profile, it injects those vars into the process environment.
GhosttyRuntime already creates surfaces with configurable environments, so this is mechanically feasible.