Configure a recommended AI assistant configuration

Configure Che to install a recommended Lola module in every workspace at startup. Developers can replace the module with their own or disable the installation.

The configuration uses two objects and requires no change to the che-operator or to the DevWorkspace operator:

  • An init container, lola-init, that every workspace pod runs before the tools container. The container installs the module with Lola into /home/user.

  • A ConfigMap with the module URL and ref. The che-operator copies the ConfigMap to every namespace and mounts it as environment variables.

Prerequisites
  • An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

  • The persistent user home is enabled, which is the default. The init container mounts the persistent-home volume, which Che defines only when spec.devEnvironments.persistUserHome.enabled is true. See Persistent user home.

  • The module repository is prepared as described in Prepare a Lola module for Che workspaces.

  • The image quay.io/che-incubator/lola-init is available to every namespace. The image is public and is built for amd64 and arm64. Pin it by digest: docker buildx imagetools inspect quay.io/che-incubator/lola-init:latest prints the digest of the multi-architecture index.

Procedure
  1. Create the ConfigMap with the module URL and ref in the eclipse-che namespace:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: lola-config-default
      namespace: eclipse-che
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
      annotations:
        controller.devfile.io/mount-as: env
    data:
      LOLA_DEFAULT_REPO_URL: https://github.com/<org>/<module-repo>.git
      LOLA_DEFAULT_REPO_REF: main
    • Replace the URL and the ref with the values of your module.

    • Remove LOLA_DEFAULT_REPO_REF to install the default branch of the repository.

    • Keep both labels. They make the che-operator synchronize the ConfigMap to every namespace.

  2. Add the init container to the eclipse-che custom resource. Check whether the list exists:

    $ kubectl get checluster eclipse-che -n eclipse-che -o jsonpath='{.spec.devEnvironments.initContainers}'
  3. If the list is empty, add the entry with a merge patch:

    spec:
      devEnvironments:
        initContainers:
          - name: lola-init
            image: quay.io/che-incubator/lola-init@sha256:<digest>
            imagePullPolicy: IfNotPresent
            workingDir: /home/user
            volumeMounts:
              - name: persistent-home
                mountPath: /home/user/
  4. If the list already contains entries, append the entry with a JSON patch. A merge patch replaces the whole list:

    $ kubectl patch checluster eclipse-che -n eclipse-che --type json -p \
      '[{"op":"add","path":"/spec/devEnvironments/initContainers/-","value":{"name":"lola-init","image":"quay.io/che-incubator/lola-init@sha256:<digest>","imagePullPolicy":"IfNotPresent","workingDir":"/home/user","volumeMounts":[{"name":"persistent-home","mountPath":"/home/user/"}]}}]'
  5. Start a workspace. Workspaces that were running before the change keep their pod and get the init container at their next start.

Verification
  • Confirm that the workspace pod contains the init container:

    $ kubectl get pod -l controller.devfile.io/devworkspace_name=<workspace-name> \
      -o jsonpath='{.items[0].spec.initContainers[*].name}'
  • Read the init container log:

    $ kubectl logs -l controller.devfile.io/devworkspace_name=<workspace-name> -c lola-init

    A successful installation reports the following line:

    [lola-init] ok module=<module-name> origin=default mode=install warnings=0 agents=<assistant-list>
  • In the workspace, /home/user/.lola/init-status contains the same result.

    The mode is mode=install on the first start, mode=update when the repository, the ref and the set of assistants are the same as last time, and mode=switch when one of them changed.

Choosing the AI assistants

The init container installs the module for the assistants that LOLA_AGENTS names: one assistant, a comma-separated subset, or all. Install the same module for every assistant rather than one module per assistant. With no value set, the container installs Claude Code.

Supported values are claude-code, opencode, gemini-cli, cursor, copilot-cli, copilot-vscode, openclaw, a comma-separated combination of them, and all. all installs for every assistant that Lola installs by default, including assistants that Lola adds later. Lola leaves out copilot-cli there, because it writes the same location as copilot-vscode: add copilot-cli to the list explicitly to cover it. An unknown name fails the installation: the status file reports failed and names the value.

The examples below show only the env part of the entry. Add it to the lola-init entry that you created in the procedure, which keeps its image and its persistent-home mount.

One assistant for every workspace

Set LOLA_AGENTS on the init container.

spec:
  devEnvironments:
    initContainers:
      - name: lola-init
        env:
          - name: LOLA_AGENTS
            value: opencode
Several assistants in one workspace

List the assistants, separated by commas. Order and duplicates do not matter.

spec:
  devEnvironments:
    initContainers:
      - name: lola-init
        env:
          - name: LOLA_AGENTS
            value: claude-code,opencode
Every assistant that Lola supports

Set the value to all. The container then installs without naming a target, so one installation covers every assistant that Lola installs by default, except copilot-cli.

spec:
  devEnvironments:
    initContainers:
      - name: lola-init
        env:
          - name: LOLA_AGENTS
            value: all
A different set for some developers

Each developer adds LOLA_AGENTS to the lola-config Secret in their own namespace. The recommended module stays, and only the set of assistants changes. Adding LOLA_REPO_URL to the same Secret replaces the module as well. See Override the recommended AI assistant configuration.

stringData:
  LOLA_AGENTS: claude-code,gemini-cli

A change to the list behaves like a change of the repository or the ref: the init container removes the module from every assistant of the previous set, then installs it for the new one.

  • Change the module or the ref: edit the ConfigMap. The che-operator updates the copies in the user namespaces and the change applies at the next workspace start. A changed URL or ref removes the previous module and installs the new one.

  • Select the AI assistants: add LOLA_AGENTS to the environment of the init container. See Choosing the AI assistants. An image that does not support this variable always installs Claude Code.

  • Update the image: read the new index digest from the registry and replace it in the eclipse-che custom resource. Do not use a digest from a build log.

  • Roll back: remove your entry from spec.devEnvironments.initContainers and delete the ConfigMap. Workspaces stop receiving the configuration at their next start. Content that is already installed in user homes remains.

    List the entries and note the position of lola-init, counting from 0:

    $ kubectl get checluster eclipse-che -n eclipse-che \
      -o jsonpath='{.spec.devEnvironments.initContainers[*].name}'

    Remove that position, then delete the ConfigMap:

    $ kubectl patch checluster eclipse-che -n eclipse-che --type json \
      -p '[{"op":"remove","path":"/spec/devEnvironments/initContainers/<index>"}]'
    $ kubectl delete configmap lola-config-default -n eclipse-che

    When lola-init is the only entry, removing the whole initContainers key has the same effect. With other init containers in the list, remove only the entry of lola-init: removing 0 deletes the first entry, which is not necessarily lola-init.

Creating or modifying the ConfigMap restarts the running workspaces that receive the synced copy, which is every namespace by default. Apply the change in a quiet period. To try the configuration on a few workspaces first, add the controller.devfile.io/mount-to-devworkspace-include annotation to the ConfigMap.

A failure in the init script does not block the workspace start. The container records the failure in /home/user/.lola/init-status and the workspace starts without the AI assistant configuration. The most common cause is an unreachable repository. A missing persistent-home volume is different: the container cannot start, no script runs, and the workspace start fails until the volume is enabled.