I also ran into this somewhere between Ubuntu 20.04 and 23.04, although I'm installing VSCode from Snap so it likely has more to do with the VSCode version and not Ubuntu version. I narrowed it down to the environment variable XDG_RUNTIME_DIR not being set. As a work around for now I set it in the role as follows:

    - role: gantsign.visual-studio-code-extensions
      become: true
      environment:
        # workaround so this role works. VSCode will dump errors without this env var set
        # this is a hack as the UID is hard coded. Consider opening a PR upstream
        XDG_RUNTIME_DIR: "/run/user/1000"
      users:
        - username: "{{ ansible_user_id }}"
          visual_studio_code_extensions:
            - eamodio.gitlens
            [...]

This is obviously not a robust solution for a few reasons but this should fix it for people if they want a work around. Issues with this fix:

1. This hard codes the UID of the target user.
2. I don't know enough about XDG and that particular var to know if that is to be counted on as a robust solution (relying on /run/user as a good base for XDG_RUNTIME_DIR in all cases.
3. Requiring users of an Ansible role to set env vars seems a little clunky.

Some thoughts on more robust ways to deal with this:

1. Rather than going to /run/user/..., create a new folder in /tmp with correct ownership and permissions (see https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables )
2. Count on /run/user/, but dynamically check the UID of the target user and set that in there. (Not sure if this is a good idea).
3. Use become_method: machinctl as suggested here. This requires installing extra dependencies which is kind of annoying.
4. Some other more sanctioned method of populating XDG_RUNTIME_DIR dynamically based on the target user.

This role is using AnsibleModule.run_command which can be passed in extra env vars to set in the context for running programs (https://docs.ansible.com/ansible/latest/reference_appendices/module_utils.html). Again, not sure if that's the best way to handle this, but that would make a pretty easy and opaque fix for users of this role.

Why on earth is any STDERR output treated as a hard error?

Passing any flags to VSC that are for Chromium/Electron will fail this alone irregardless of RC, so good luck having any global Electron/Chromium configs.

If this was implemented because VSC does not always throw an error code on an error, file that upstream, don't try to work around it downstream.

[0] % code --ozone-platform=wayland --list-extensions > /dev/null
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.

[0] % 

@brydling @lifeisafractal

Please try to reproduce this on current VSC and extension.

If you are able to, please post your full playbook and how you're launching it, output with -vvv (please wrap with <details>triple backticked content</details>).

Afterwards manually apply #138 and once again post -vvv from that - post it even if that PR fixes your issue, it would be nice to confirm it works fine.

Are you sure you need become? This is my role.

- name: Install Visual Studio Code extensions
  ansible.builtin.include_role:
    name: gantsign.visual-studio-code-extensions
  vars:
    visual_studio_code_extensions_build: oss
    users:
      - username: '{{ username }}'
        visual_studio_code_extensions:
          - redhat.ansible               # Ansible support
          - vsciot-vscode.vscode-arduino # Arduino
          - ms-vscode.cpptools           # C/C++
          - hediet.vscode-drawio         # Draw.io Integration
          - eamodio.gitlens              # GitLens
          - oderwat.indent-rainbow       # ident-rainbow
          - timonwong.shellcheck         # shellcheck
          - simonsiefke.svg-preview      # SVG preview
        visual_studio_code_extensions_absent:
          - simonsiefke.svg-preview      # Test removing an already installed thing
          - zbr.vscode-ansible           # Test removing a thing not installed