Workspaces, trust and project binding

You open folders in the Editor as in Code - OSS. Neural Inverse adds two things: workspace trust is decided by your organisation's governance, and each folder is bound to the organisation project its git repository belongs to, so organisation context, agent instruction files, team work and vault requests know where you work.

Workspace trust

Workspace trust works as in Code - OSS: an untrusted folder opens in restricted mode, and features that run code from the folder (tasks, debugging, many extensions) stay off until you trust it. Several Neural Inverse domain modules only run in a trusted workspace.

Changing workspace trust is a governed action. When your organisation's policy has a rule for it (appRules.workspaceTrust), trusting a folder can be allowed, denied, or need approval, like any other governed action. See Approvals and signatures.

These settings are always governed, with or without an organisation policy: security.workspace.trust.enabled, security.workspace.trust.untrustedFiles and security.restrictUNCAccess. A value for them in a settings file is ignored; they take their value from managed policy or their default.

Project binding

For every open folder, the Editor works out which repository it is and asks your organisation's Govern deployment which project that repository belongs to. The folder makes a claim; the server decides; managed policy is strongest.

What the Editor reads and sends

• It looks for .git in the folder and the folders above it, and reads the git files directly. It never runs git for this, so nothing a repository configures (hooks, core.fsmonitor, credential helpers) can start.
• It collects the remotes, in this order: origin, the remote the current branch tracks, upstream, then the others, at most 8.
• It normalises each address the way Govern does (for example https://github.com/acme/fw.git and git@github.com:acme/fw.git become the same key), and removes any user name, password or token. An address with a password, query or fragment is not sent at all.
• It sends the candidate addresses to the server and accepts a project only when the answer names one of the addresses it sent.

The folder's path, the repository root and the git directory never leave the machine. Nothing in the folder (a file, a setting, a remote's name) can name a project, a space or a server.

See the binding

Run Show Workspace Bindings from the Command Palette. The Workspace Binding view, Where this window works, lists each folder, its repository, the remote that matched, the project and the state. Look Up Again asks the server again.

The status bar shows the binding of the active folder. When several folders are open, the binding follows the folder of the active editor.

Binding states

When the server rate-limits lookups, the Editor waits the time the server asks (60 seconds when it gives none, at most 15 minutes) and does not retry on its own; it looks again when the folder is next used or you choose Look Up Again.

Bindings are cached for a minute and read again when the branch, remotes or folders change, when you sign in or out, when the policy changes, and when Govern reports that a project's repositories changed.

For administrators: pin or forbid repositories

The managed policy NeuralInverseKeystoneWorkspaceBindingPolicy (setting neuralInverse.keystone.workspaceBindingPolicy) takes a JSON value. Only the managed value is read.

{ "rules": [ { "repository": "https://<host>/acme/secret-*", "forbid": true },
             { "repository": "https://<host>/acme/**", "projectId": "<project id>" } ],
  "unboundAgents": "refuse" }

• The first matching rule applies.
• forbid: the repository is never looked up. When it is the chosen remote the binding is refused; when it is another remote it is left out of the candidates.
• projectId: Govern must answer with that project, otherwise the binding is refused.
• unboundAgents: "refuse": an agent session working in a folder that is not bound gets no organisation context.
• A policy that cannot be read refuses every binding.

Where folder data stays

When a vault request needs to identify a folder, the Editor sends a digest of the folder path (an HMAC under a random key made once per installation and never sent), never the path itself. Clearing the app's storage makes a new key and so new digests. See Secrets and agent terminals.