Will OpenCode 2.0 Mix Up Projects on a Shared Mac in 2026?

OpenCode 2.0’s shared backend is not a multi-person isolation feature. If several people need one Mac, verify the macOS accounts, project directories, credentials, and service access separately; until you do, do not use one shared user session for different lab projects.

This guide is for research group leads deciding whether to share a Mac for OpenCode 2.0, lab administrators checking account and project boundaries, and research software developers moving from a personal setup to a team-accessible Mac.

Last updated November 3, 2026. We checked the OpenCode V2 documentation, its official change log, and Apple’s macOS account and file-permission guidance.

The key distinction: sharing a physical Mac does not automatically mean sharing an OpenCode session, and separate sessions do not automatically isolate people.

Start by identifying what “shared Mac” means

A team can mean different things by a shared Mac. Those setups have different boundaries. Before testing OpenCode, write down which arrangement is actually in use.

The OpenCode V2 CLI documentation describes the default shared backend as managing sessions, configuration, integrations, permissions, and tool execution for the current user account. It also documents standalone use and connecting to a specified server. Read that as a description of the service’s responsibilities and connection options—not as a promise that people sharing one macOS account are isolated from one another. See the V2 configuration documentation.

The first operational question is not “Are the clients separate?” It is “Which macOS account owns the process, and which backend does each client reach?”

Shared backend state needs a clear owner

A separate window, browser tab, or client does not prove that a person has a separate backend. Two clients may point at the same service, while two people who use the same macOS login may also share access to that account’s files and configuration.

For each person, record these facts before opening a real project:

• The macOS account currently logged in.
• The OpenCode mode in use: standalone or connected to a specified server.
• The service address or connection target.
• The sessions visible through that connection.
• The location and ownership of the configuration files.
• Which account owns the running backend process.

Use the configuration documentation to check the actual settings in the environment, rather than assuming that a different client automatically loads different settings. OpenCode behavior can change between releases; compare the installed version with the official change log when a team updates its setup.

A practical test is to create a temporary session under a non-sensitive test account, then connect from each intended client. Record what each client can see and which backend it reaches. Do not treat one successful test as a universal guarantee: repeat it for the account and connection pattern the team will actually use.

Project crossover usually begins with paths and permissions

OpenCode session separation and file-system separation are different controls. A session may have its own conversation context, but the process still acts within the permissions of the macOS user running it. If two people work under one login, both may be able to reach files available to that login.

Project crossover can happen through ordinary workflow mistakes:

• A client opens the wrong working directory.
• Two people edit the same worktree or shared checkout.
• A command writes generated files to a shared output directory.
• The active Git branch is not the branch a researcher expects.
• A project folder is readable or writable by a broader group than intended.

Before using real research code, make a test repository without sensitive data. From each intended account or client, confirm the current working directory, branch, readable files, and write destination. Make a harmless change and check exactly where it lands. For concurrent work, Git’s git worktree documentation describes how separate working directories can be associated with repository work. A worktree can help prevent accidental edits in the same checkout, but it does not replace macOS account and file-permission controls.

Apple documents how to add a user account on a Mac and how to manage file and folder permissions. Use those operating-system controls to decide who can read or change research folders. Do not infer access boundaries from the OpenCode session list.

Tool permissions do not replace macOS account boundaries

OpenCode permissions govern what the application is allowed to do within its configured environment. They are not equivalent to creating a separate operating-system user. The OpenCode permissions documentation is the reference for reviewing application-level permission behavior; verify the settings in the version and configuration your group actually runs.

Then check what the macOS user can reach outside the application:

• Which project folders can the user read and write?
• Can a command access shared storage, removable volumes, or other users’ files?
• Which environment variables are present in the shell?
• Where are provider credentials stored, and which user can read them?
• Are tokens, keys, or research data written into logs or generated files?
• Who can reuse the account or access an unlocked session?

If several people use one macOS login, they may be able to access files and secrets available to that user. A restrictive application setting cannot make the operating-system account private from another person who can use the same login. For teams that need distinct credentials or project ownership, separate macOS accounts provide a clearer boundary to test.

Treat a shared login as shared access to that user’s environment unless you have verified otherwise. Do not place real credentials or sensitive research data in a test designed to discover who can see them.

Remote access adds another boundary to verify

A local connection, a connection from the lab network, and access from outside the institution are not the same exposure. OpenCode’s remote-service documentation says remote service access must be considered and configured deliberately. Check the installed version’s instructions rather than assuming that a service is reachable—or protected—in a particular way.

Use this review before allowing a remote client:

• Confirm whether remote service access is enabled.
• Identify the address the service listens on.
• Confirm the authentication method and who holds its credentials.
• List which client machines and network locations should be allowed.
• Test an allowed connection and a connection that should be denied.
• Confirm who can start, stop, or reconfigure the service.
• Review whether the institution permits the data and access pattern involved.

Authentication and encrypted transport are useful controls, but neither is a substitute for institutional approval. The lab still needs to apply its own rules for research data, account management, and network access.

Check the setup before assigning real projects

Use this checklist with a test project first. Keep the evidence: a team should be able to explain what it verified, not merely report that the setup appeared to work.

• [ ] Each user’s macOS login and account owner are known.
• [ ] Each client’s OpenCode mode and server target are recorded.
• [ ] The team has checked which sessions and configurations are visible.
• [ ] Each user’s project path, Git branch, and output directory are confirmed.
• [ ] Read and write access to project folders is tested under the intended accounts.
• [ ] Tool permissions and shell access are reviewed.
• [ ] Provider credentials and environment variables have a named owner.
• [ ] Remote access is either disabled or deliberately configured and tested.
• [ ] The group has checked current institutional rules for research data and remote access.

For a convenient audit trail, record the date, OpenCode version, macOS account, client connection target, test repository, and observed results. Recheck when the group changes the OpenCode version, service configuration, account permissions, or remote access setup. The official release history is useful for spotting changes that may warrant another review.

FAQs

What does OpenCode 2.0’s shared backend keep track of?

OpenCode’s V2 documentation describes the default backend as managing sessions, configuration, integrations, permissions, and tool execution for the current user account. That describes the backend’s responsibilities; it does not establish a separation boundary between people who share one macOS login. Check which account owns the service and which server each client actually reaches.

Can one lab member see another member’s project on a shared Mac?

It depends on the macOS account, project path, file permissions, and service connection. Separate OpenCode sessions do not by themselves prove that files are isolated. Test with a non-sensitive repository: confirm the logged-in account, working directory, Git branch, readable files, and write destination before using real research code.

How should a team check remote OpenCode service access?

Confirm whether remote service access is enabled, identify the listening address and authentication method, and test from an explicitly allowed client and a client that should be denied. The OpenCode remote-service documentation treats remote access as something to configure deliberately. A password or encrypted connection does not replace your institution’s security review.

Should a research group share one macOS account or create separate accounts?

Use separate macOS accounts when people need distinct project access, credentials, or ownership of work. Share one account only if the team has verified the service target, file permissions, credentials, and access rules, and accepts the remaining shared-user exposure. If you cannot demonstrate those boundaries, separate accounts or hosts are the safer fallback.

Choose the account and host boundary by risk

Use these decision branches after the test, not before it:

• If one person uses the Mac and the service locally: verify the current account, project directory, and credentials. A shared team setup may not be necessary.
• If multiple people need access but have different projects or credentials: create separate macOS accounts, then test folder permissions and service ownership for each.
• If multiple clients must connect to one backend: document who owns that service, what each client reaches, and which sessions and files are visible. Do not infer isolation from separate client windows.
• If the team cannot prove the boundaries: do not put different groups’ real projects into the same user session. Split accounts or use separate host environments.
• If remote access is needed: enable and test it only after confirming the allowed clients, authentication, and institutional rules.

A remote macOS host can be a useful option when a group needs an interactive Mac environment without assigning one physical machine to every researcher. It does not, by itself, create multi-user isolation or guarantee that a particular data-handling policy is satisfied. Before choosing a rented environment, confirm how accounts and access are handled for the intended arrangement. You can review metalvnc’s Mac service information, check its help information, or contact metalvnc to clarify the setup before moving research work.

If your current shared Mac relies on one login, informal folder rules, and credentials stored in a common environment, its weak points are unclear ownership, broader file access, and hard-to-audit remote connections. A rented Mac may be a better fit when you need a separate interactive macOS host for a defined period—but only after you verify the account and data boundaries for your group. For long-running workloads that need dedicated physical interfaces or tightly controlled local hardware, a lab-owned Mac may remain the better choice.

Frequently asked questions