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 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, update, or uninstall 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.

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.

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.
Note

The assistant-enabled setting only enforces a policy when set. When absent from /etc/rstudio/profiles, it imposes no constraint on Posit Assistant availability.

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, update, and uninstall 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.

Before setting it to 0, point the posit-assistant-path option in rsession.conf at an administrator-managed installation to provide a copy for the sessions to use. Doing so ends the search: if the path holds no valid installation, sessions report Posit Assistant as not installed rather than falling back to a copy bundled with the Workbench release, so a typo or an unmounted share is visible instead of a silent downgrade. Leave it unset to use the bundled copy where the release supplies one.

What users see when it is off

  • No update checks. The session makes no requests to cdn.posit.co.
  • No install, update, or uninstall 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: |
      {
        "assistant": { "telemetry": false }
      }
    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