Posit Assistant Admin Controls

Workbench | Preview

WarningPreview feature

This feature is in preview. Preview features are unsupported and may face breaking changes in a future release. Any issues found in the feature will be addressed during the regular release schedule; they will not result in immediate patches or hotfixes.

We encourage customers to try these features and we welcome any feedback via Posit Support, but we recommend that the feature not be used in production until it is in general availability (i.e., officially released as a full feature). To provide feedback, please email your Posit Customer Success representative or and specify that you are trialing this feature.

Posit Assistant is an AI coding assistant built specifically for data science workflows. For end-user documentation, see the Posit Assistant documentation.

Posit Workbench administrators control Posit Assistant through /etc/rstudio/profiles, using global ([*]), per-group ([@groupname]), and per-user ([username]) sections. Workbench processes the file from top to bottom, so settings matching the current user that occur later in the file override ones that appeared prior. See User and Group Profiles for the full profiles syntax.

Setting Effect
assistant-enabled Whether Posit Assistant is available at all.
assistant-installation-enabled Whether users can install or update their own copy.
assistant-settings-enforced Posit Assistant settings users cannot override.
assistant-settings-default Posit Assistant settings users can override.

The two assistant-settings-* settings point at a JSON file in the Posit Assistant settings.json schema. They apply to RStudio Pro and Positron Pro sessions, the editors that run Posit Assistant. Because Workbench delivers them through the session environment, anything started inside the session inherits them, including the Posit Assistant command-line interface.

For what those files can contain, including model selection, agent approval mode, permissions, and plugin controls, see the Posit Assistant configuration file reference.

Important

These files carry non-secret settings only. Do not put API keys, tokens, or any other credential in them, because they are readable by the session and are not a secret store. Credentials belong in the managed-credential system, the same rule the providers.json files follow.

Language model providers

Posit Assistant supports multiple language model providers, including Anthropic, GitHub Copilot, Amazon Bedrock, Snowflake Cortex, and Microsoft Foundry. Use ai-providers-enforced and ai-providers-default to enable or disable providers, constrain their models, and supply connection settings. Some providers support Workbench-managed credentials. See AI Provider Admin Controls for the full list of providers and their configuration options, and Provider setup prerequisites for Workbench-managed credential setup.

Configuring the assistant-enabled profile setting

The setting takes one of two values:

Value Behavior
1 Posit Assistant is enabled for the matched users/groups.
0 Posit Assistant is disabled and cannot be re-enabled by the user.

Example

The following example disables Posit Assistant for all users and then re-enables it for members of the data-scientists group. It also disables access for a specific contractor account:

/etc/rstudio/profiles
[*]
assistant-enabled = 0

[@data-scientists]
assistant-enabled = 1

[jcontractor]
assistant-enabled = 0

Configuring the assistant-installation-enabled profile setting

This setting is about who installs Posit Assistant, not whether it is available. assistant-enabled turns the feature off; assistant-installation-enabled leaves it on but takes installation away from the user, so the session uses only the copy you provide.

Value Behavior
1 Users can install and update their own copy of Posit Assistant.
0 An administrator manages installation. The session uses only the administrator-managed or bundled copy.

It applies to RStudio Pro sessions.

A user’s own copies live in pai/versions under their RStudio data directory: ~/.local/share/rstudio/pai/versions by default, or under RSTUDIO_DATA_HOME or XDG_DATA_HOME if set. Each install or update adds a version directory and sessions never remove the older ones, so a user’s disk use grows with each update. A user can reclaim the space by deleting pai while they have no RStudio Pro sessions running, as described in Removing Posit Assistant. Versions you install are removed with cleanup.

When it is 0, sessions choose between the copy bundled with Workbench and the administrator-installed version, as described in Version selection. To install a newer version than the bundled copy without upgrading Workbench, see Upgrading Posit Assistant for RStudio Pro.

What users see when it is off

  • No update checks. The session makes no requests to cdn.posit.co.
  • No install or update commands. The session refuses those requests and hides the corresponding UI.
  • An administrator notice in Global Options, in place of the update-check interval.
  • If neither an administrator-managed nor a bundled copy resolves, the chat pane reports “Posit Assistant is managed by your administrator and is not currently installed”.

A user who already installed their own copy keeps it on disk (the session ignores it rather than removing it) and switches to the administrator-managed or bundled copy, which might be an older version.

Example

The following example takes installation away from everyone, then returns it to members of the assistant-maintainers group:

/etc/rstudio/profiles
[*]
assistant-installation-enabled = 0

[@assistant-maintainers]
assistant-installation-enabled = 1

assistant-settings-enforced

Property Value
Type path to a JSON file (in the Posit Assistant settings.json schema)
Default unset (no enforced settings)

Path to a JSON file holding Posit Assistant settings that users cannot override. Workbench resolves the setting per user at session launch and forwards the file’s contents to the session unmodified.

A relative path resolves against the directory that contains the profiles file (/etc/rstudio/ by default). Workbench uses an absolute path as-is.

/etc/rstudio/profiles
[*]
assistant-settings-enforced = /etc/rstudio/assistant/enforced.json

assistant-settings-default

Property Value
Type path to a JSON file (in the Posit Assistant settings.json schema)
Default unset (no default settings)

Path to a JSON file holding Posit Assistant settings that users can override. Use it to give users a working starting configuration rather than a constraint. Path resolution is identical to assistant-settings-enforced.

/etc/rstudio/profiles
[*]
assistant-settings-default = /etc/rstudio/assistant/defaults.json

Setting both

The two settings are independent, and setting both is the common case. Posit Assistant applies them at opposite ends of its own settings merge:

  1. assistant-settings-default, which the user’s own settings override.
  2. The user’s own Posit Assistant settings.
  3. assistant-settings-enforced, which overrides both.

So the same field can appear in both files without conflict. The default one is what a user starts from, and the enforced one is what they end up with.

Scoping the assistant-settings-* settings

For each setting, Workbench reads the /etc/rstudio/profiles file top to bottom and uses the last section that applies the setting to a given user. If the setting assistant-settings-enforced is defined in more than one section, Workbench uses only the value from the last section that applies to the user and ignores the value from any previous sections.

Additionally, Workbench processes each setting separately: a section that sets only one of the two leaves the other setting’s value from earlier sections in effect.

/etc/rstudio/profiles
[*]
assistant-settings-default = /etc/rstudio/assistant/defaults.json
assistant-settings-enforced = /etc/rstudio/assistant/enforced.json

[@contractors]
assistant-settings-enforced = /etc/rstudio/assistant/contractors.json

In this example, for assistant-settings-enforced, contractors members get contractors.json and everyone else gets enforced.json.

For assistant-settings-default, every user gets defaults.json, including contractors members. Workbench processes each setting individually, which is why a contractors member gets contractors.json for assistant-settings-enforced but defaults.json for assistant-settings-default.

Because the replacing file is used whole, contractors.json must restate anything from enforced.json that should still apply. Workbench logs each such replacement to rserver.log, naming both files, so this is visible when a global restriction unexpectedly stops applying to one group.

Applying changes

After editing /etc/rstudio/profiles, restart Workbench to apply the changes:

Terminal
sudo rstudio-server restart

The updated settings take effect for sessions launched after the restart. Existing sessions keep the configuration they received at launch.

Changes to the assistant-settings-* settings, and to the files they reference, can be applied with sudo rstudio-server reload instead of a full restart. Reloading re-reads the profiles file and every file it references. If Workbench cannot read a referenced file or the file contains invalid JSON, it rejects the reload and keeps the previously loaded configuration. See Reloading configuration values for more about the reload command.

Helm chart configuration

On Kubernetes deployments using the Workbench Helm chart, /etc/rstudio/profiles is managed via config.server.profiles in values.yaml:

values.yaml
config:
  server:
    profiles:
      "*":
        assistant-enabled: 0
        assistant-installation-enabled: 0
      "@data-scientists":
        assistant-enabled: 1

There is no host filesystem to place the assistant-settings-* files on, so supply each as its own config.server entry and point the setting at it by relative path:

values.yaml
config:
  server:
    assistant-settings-enforced.json: |
      {
        "approvalMode": "normal"
      }
    profiles:
      "*":
        assistant-settings-enforced: assistant-settings-enforced.json

The chart mounts every config.server entry into the same server configuration directory, so the JSON file lands alongside the rendered profiles file. A relative path resolves against that directory automatically, without hard-coding the chart’s mount path.

See the Configuration files section of the Helm chart README for the full list of supported config keys and their mapping to files on disk.

Back to top