DEV Community: KAMEGAWA Kazushi

Make Intune App Publishing Much Easier with Relaypublisher

KAMEGAWA Kazushi — Sun, 25 Oct 2026 07:37:42 +0000

Note: I originally wrote this article in Japanese, and I used AI to translate it into English. You can read the original post here: RelaypublisherでIntuneへのアプリ登録を劇的に改善する

Uploading Windows and macOS apps to Intune one by one is painful. At the end of August, I built a tool to fix this and started using it. In my environment, it has made things much easier.

KAMEGAWA Kazushi

Sep 1

I Built RelayPublisher: A winget-like Publishing Workflow for Microsoft Intune

#opensource #dotnet #microsoft #intune

3 min read

I designed the tool, so of course it fits my own needs best. Still, some parts are a bit hard to understand, so I want to explain them in more detail. In this article, I use PowerShell 7 (the MSIX version) as an example. I walk through every step, from writing the manifest to automatic publishing to Intune with Azure Pipelines.

Tool: kkamegawa/Relaypublisher
Skill for writing manifests: tfsugjp/skills - relaypublisher-manifest

If you have written a winget manifest before, the syntax will feel familiar. I made it close to winget on purpose. Even so, you will probably fail a few times at first, so the skill above helps a lot. I run everything on Azure DevOps, so this article uses Azure Pipelines. If you use GitHub Actions, AI can convert the pipeline for you quite easily.

Steps

Register an application in Entra ID
Write the manifest (YAML). The skill makes this easy.
Put the YAML files in a private repository (a public one also works, but…). A winget-like folder structure is a good choice.
Create the CI (Azure Pipelines)
Get relaypublisher inside the CI
Merge a PR and test it

Register an application in Entra ID

relaypublisher registers apps in Intune through Microsoft Graph. So first, I register an application in Entra ID and make it usable from Azure DevOps or GitHub.

In the Entra admin center, create a new App registration.
Under API permissions, add the Microsoft Graph application permissions needed for Intune app management, and grant admin consent. (Please check the README for the exact permissions.)
In Azure DevOps, create an Azure Resource Manager connection under Service connections. I recommend workload identity federation, because you don't need to manage secrets.
Write down the connection name, because the pipeline uses it. (In this article, it is Microsoft Azure.)

Save the tenant ID as a protected (secret) pipeline variable named EXPECTED_TENANT_ID.

Tips for writing the YAML

You can write a manifest by hand, but the relaypublisher-manifest skill in tfsugjp/skills makes it much easier. Load the skill into an agent such as GitHub Copilot or Claude Code, and ask something like "Create a manifest to deploy the PowerShell 7.6.8 MSIX to Intune." It will create a template for you. I ask Copilot to do this every time.

Some packages, like MSIX, can't become a Win32 app as they are. For these, you will probably need install, uninstall, and detection scripts. On Windows, you create an .intunewin file with IntuneWinAppUtil.exe. This tool is not open source, so relaypublisher downloads the latest version each time. It only runs on Windows, so if you build Windows packages, use a CI that has Windows runners.

Detection script (detect-x64.ps1)

$version = [version]'7.6.8.0'
$architecture = 'X64'

$installed = Get-AppxPackage -AllUsers -Name Microsoft.PowerShell -ErrorAction Stop |
    Where-Object { $_.Version -eq $version -and $_.Architecture.ToString() -eq $architecture }
$provisioned = Get-AppxProvisionedPackage -Online -ErrorAction Stop |
    Where-Object {
        $_.DisplayName -eq 'Microsoft.PowerShell' -and
        $_.Version -eq $version -and
        $_.PackageName -match '_x64_'
    }

if ($installed -or $provisioned) {
    Write-Output 'PowerShell 7.6.8 x64 is installed.'
    exit 0
}

exit 1

Install script (install-msix.ps1)

$ErrorActionPreference = 'Stop'

$bundlePath = Join-Path $PSScriptRoot 'PowerShell-7.6.8.msixbundle'
if (-not (Test-Path -LiteralPath $bundlePath -PathType Leaf)) {
    Write-Error "PowerShell MSIX bundle not found: $bundlePath"
    exit 1
}

try {
    Add-AppxProvisionedPackage -Online -PackagePath $bundlePath -SkipLicense -ErrorAction Stop | Out-Null
}
catch {
    Write-Error "Failed to provision the PowerShell MSIX bundle: $_"
    exit 1
}

exit 0

Uninstall script (uninstall-msix.ps1)

$ErrorActionPreference = 'Stop'
$version = [version]'7.6.8.0'

try {
    Get-AppxPackage -AllUsers -Name Microsoft.PowerShell -ErrorAction Stop |
        Where-Object { $_.Version -eq $version } |
        ForEach-Object {
            Remove-AppxPackage -Package $_.PackageFullName -AllUsers -ErrorAction Stop
        }

    Get-AppxProvisionedPackage -Online -ErrorAction Stop |
        Where-Object { $_.DisplayName -eq 'Microsoft.PowerShell' -and $_.Version -eq $version } |
        ForEach-Object {
            Remove-AppxProvisionedPackage -Online -PackageName $_.PackageName -AllUsers -ErrorAction Stop | Out-Null
        }
}
catch {
    Write-Error "Failed to remove the PowerShell 7.6.8 MSIX package: $_"
    exit 1
}

exit 0

Manifest

SchemaVersion: "1.0"
PackageIdentifier: Microsoft.PowerShell
PackageName: PowerShell
Publisher: Microsoft Corporation
Description: PowerShell 7 cross-platform automation and configuration tool.
PackageVersion: 7.6.8
AssignmentSync: merge

Apps:
  - Platform: windows
    Architecture: x64
    Categories:
      - Data management
      - Computer management
      - Development & Design
      - Productivity
    InstallerType: win32
    DisplayName: PowerShell [Windows x64]

    Package:
      IntuneWin:
        SetupFile: PowerShell-7.6.8.msixbundle

      RepositoryFiles:
        - Source: scripts/windows/powershell/7.6.8/install-msix.ps1
          Destination: install-msix.ps1
        - Source: scripts/windows/powershell/7.6.8/uninstall-msix.ps1
          Destination: uninstall-msix.ps1

      ExternalFiles:
        - Type: githubRelease
          Owner: PowerShell
          Repository: PowerShell
          Tag: v7.6.8
          AssetName: PowerShell-7.6.8.msixbundle
          Destination: PowerShell-7.6.8.msixbundle
          Sha256: "A77EF80D069C342739211904B7917769C190DD0C9CCBE492F21D637F318B5E96"
          Auth:
            Type: none

    Install:
      CommandLine: powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\install-msix.ps1
      UninstallCommandLine: powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\uninstall-msix.ps1
      InstallExperience: system
      RestartBehavior: suppress

    Detection:
      Type: script
      ScriptFile: scripts/windows/powershell/7.6.8/detect-x64.ps1
      RunAs32Bit: false
      EnforceSignatureCheck: false

    Requirements:
      MinimumOSVersion: 10.0.19045
      Architecture: x64

    Assignments:
      - Target: group
        GroupId: "<object ID of the target group>"
        Intent: required

Here are the key points.

💡 Tip

ExternalFiles: Don't put the installer itself in the repository. Get it from a GitHub Release instead. Always set Sha256, so a tampered file will never get in.

RepositoryFiles: These scripts from the repository are bundled into the intunewin file.

Detection: The detection script is not included in the package. It is registered as an Intune detection rule.

Assignments: This item is unique to relaypublisher. winget manifests don't have it.

Put the YAML in a private repository

A manifest includes things like the IDs of target groups, so I recommend keeping it in a private repository (Azure Repos, for example).

A folder structure like winget-pkgs makes management easier.

manifests/
  Microsoft/
    PowerShell/
      7.6.8/
        Microsoft.PowerShell.yaml
scripts/
  windows/
    powershell/
      7.6.8/
        install-msix.ps1
        uninstall-msix.ps1
        detect-x64.ps1
.azurepipelines/
  intuneapps.yml
  install-relaypublisher.ps1
  resolve-manifest-base.ps1

The big difference from winget is that you can choose which groups get the app. So if you want to deploy the same app to different groups, split the folders and create a separate manifest for each.

manifests/Microsoft/PowerShell/7.6.8/dev/Microsoft.PowerShell.yaml      # For the dev team (required)
manifests/Microsoft/PowerShell/7.6.8/general/Microsoft.PowerShell.yaml  # For the whole company (available)

This way, you can see "which app goes to which group" just by looking at the PR diff.

Create the CI (Azure Pipelines)

The pipeline has three stages.

Stage	Agent	What it does
Validate	ubuntu-latest	Finds changed manifests with `plan` and checks them with `validate`
Package	windows-latest	Creates intunewin files with `package`
Publish	ubuntu-latest	Registers apps in Intune with `publish`

For PRs, the pipeline runs in dry-run mode and only checks things. It publishes for real only when changes are merged into main.

💡 Tip: Azure Repos users
Azure Repos ignores the pr: trigger in YAML. To run the pipeline on PRs, add it under Branch policies → Build validation for the main branch. For PR builds, Build.Reason is PullRequest, so the Publish stage automatically runs in dry-run mode.

# Pipeline that publishes manifest changes on main to Intune
name: intuneapps-$(Date:yyyyMMdd).$(Rev:r)

trigger:
  batch: false
  branches:
    include:
      - main
  paths:
    include:
      - manifests

pr: none

parameters:
  # Manual runs are dry-run by default. Set this to true only when you want to really publish.
  - name: allowManualPublish
    displayName: Publish for real on manual runs (disable dry-run)
    type: boolean
    default: false

  # If set, Validate / Package are skipped, and only the Publish stage runs again
  # using the manifest-list / intune-packages artifacts from the given run.
  - name: sourceBuildId
    displayName: Build ID of the run to re-publish from (leave empty for a normal run)
    type: string
    default: ''

variables:
  # Allow the service connection with this name for this pipeline in Azure DevOps.
  - name: azureServiceConnection
    value: Microsoft Azure

stages:
  - ${{ if eq(parameters.sourceBuildId, '') }}:
    - stage: Validate
      displayName: Validate manifests
      jobs:
        - job: Validate
          displayName: Plan and validate
          pool:
            vmImage: ubuntu-latest
          steps:
            - checkout: self
              fetchDepth: 0

            - task: UseDotNet@2
              displayName: Install .NET 10 SDK
              inputs:
                packageType: sdk
                version: 10.0.x

            - task: NuGetAuthenticate@1
              displayName: Authenticate Azure Artifacts

            - pwsh: |
                & "$(Build.SourcesDirectory)/.azurepipelines/install-relaypublisher.ps1"
                if ($LASTEXITCODE -ne 0) {
                    exit $LASTEXITCODE
                }
              displayName: Install latest relaypublisher from Azure Artifacts
              env:
                SYSTEM_ACCESSTOKEN: $(System.AccessToken)
                SYSTEM_COLLECTIONURI: $(System.CollectionUri)

            - pwsh: |
                & "$(Build.SourcesDirectory)/.azurepipelines/resolve-manifest-base.ps1"
              displayName: Resolve safe manifest base
              env:
                BUILD_REASON: $(Build.Reason)
                BUILD_REPOSITORY_ID: $(Build.Repository.ID)
                BUILD_SOURCEBRANCH: $(Build.SourceBranch)
                BUILD_SOURCEVERSION: $(Build.SourceVersion)
                BUILD_SOURCESDIRECTORY: $(Build.SourcesDirectory)
                MANIFEST_OVERRIDE: $(MANIFEST_OVERRIDE)
                SYSTEM_ACCESSTOKEN: $(System.AccessToken)
                SYSTEM_COLLECTIONURI: $(System.CollectionUri)
                SYSTEM_PULLREQUEST_TARGETBRANCH: $(System.PullRequest.TargetBranch)
                SYSTEM_TEAMPROJECT: $(System.TeamProject)

            - bash: |
                set -euo pipefail
                relaypublisher plan \
                  --repo-root "$(Build.SourcesDirectory)" \
                  --manifest-root manifests \
                  --base-ref "$(ManifestBaseRef)" \
                  --output "$(Build.ArtifactStagingDirectory)/manifest-list.json"
              displayName: Plan changed manifests
              condition: eq(variables['MANIFEST_OVERRIDE'], '')

            - pwsh: |
                $ErrorActionPreference = 'Stop'
                $planArguments = @(
                  'plan',
                  '--repo-root', '$(Build.SourcesDirectory)',
                  '--manifest-root', 'manifests',
                  '--output', '$(Build.ArtifactStagingDirectory)/manifest-list.json'
                )
                foreach ($path in ($env:MANIFEST_OVERRIDE_PATHS -split ';')) {
                    $planArguments += @('--manifest', $path)
                }
                & relaypublisher @planArguments
                if ($LASTEXITCODE -ne 0) {
                    exit $LASTEXITCODE
                }
              displayName: Plan manually selected manifests
              condition: ne(variables['MANIFEST_OVERRIDE'], '')
              env:
                MANIFEST_OVERRIDE_PATHS: $(ManifestOverridePaths)

            - bash: |
                set -euo pipefail
                relaypublisher validate \
                  --repo-root "$(Build.SourcesDirectory)" \
                  --manifest-list "$(Build.ArtifactStagingDirectory)/manifest-list.json"
              displayName: Validate manifest list

            - publish: $(Build.ArtifactStagingDirectory)/manifest-list.json
              displayName: Publish manifest list artifact
              artifact: manifest-list

    - stage: Package
      displayName: Package installers
      dependsOn: Validate
      condition: succeeded()
      jobs:
        - job: PackageWindows
          displayName: Package Windows and macOS installers
          pool:
            vmImage: windows-latest
          steps:
            - checkout: self

            - task: UseDotNet@2
              displayName: Install .NET 10 SDK
              inputs:
                packageType: sdk
                version: 10.0.x

            - task: NuGetAuthenticate@1
              displayName: Authenticate Azure Artifacts

            - pwsh: |
                & "$(Build.SourcesDirectory)/.azurepipelines/install-relaypublisher.ps1"
                if ($LASTEXITCODE -ne 0) {
                    exit $LASTEXITCODE
                }
              displayName: Install latest relaypublisher from Azure Artifacts
              env:
                SYSTEM_ACCESSTOKEN: $(System.AccessToken)
                SYSTEM_COLLECTIONURI: $(System.CollectionUri)

            - download: current
              artifact: manifest-list

            - pwsh: |
                $ErrorActionPreference = 'Stop'
                $manifestList = '$(Pipeline.Workspace)/manifest-list/manifest-list.json'
                $outputDirectory = '$(Build.ArtifactStagingDirectory)/out'
                New-Item -ItemType Directory -Force -Path $outputDirectory | Out-Null
                $list = Get-Content -LiteralPath $manifestList -Raw | ConvertFrom-Json
                if (@($list.manifests).Count -eq 0) {
                    Write-Host 'No manifests to package; producing an empty package artifact.'
                    exit 0
                }

                relaypublisher package `
                  --repo-root '$(Build.SourcesDirectory)' `
                  --manifest-list $manifestList `
                  --output $outputDirectory
                if ($LASTEXITCODE -ne 0) {
                    exit $LASTEXITCODE
                }
              displayName: Package installers

            - publish: $(Build.ArtifactStagingDirectory)/out
              displayName: Publish package artifact
              artifact: intune-packages

  - stage: Publish
    displayName: Publish to Intune
    ${{ if eq(parameters.sourceBuildId, '') }}:
      dependsOn: Package
      condition: succeeded()
    ${{ else }}:
      dependsOn: []
    lockBehavior: sequential
    jobs:
      - deployment: PublishToIntune
        displayName: Publish selected apps
        environment: intuneapps-production
        pool:
          vmImage: ubuntu-latest
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self

                - ${{ if eq(parameters.sourceBuildId, '') }}:
                  - download: current
                    artifact: manifest-list

                  - download: current
                    artifact: intune-packages

                - ${{ else }}:
                  - task: DownloadPipelineArtifact@2
                    displayName: Download manifest-list from build ${{ parameters.sourceBuildId }}
                    inputs:
                      buildType: specific
                      project: $(System.TeamProject)
                      definition: $(System.DefinitionId)
                      buildVersionToDownload: specific
                      pipelineId: ${{ parameters.sourceBuildId }}
                      artifactName: manifest-list
                      targetPath: $(Pipeline.Workspace)/manifest-list

                  - task: DownloadPipelineArtifact@2
                    displayName: Download intune-packages from build ${{ parameters.sourceBuildId }}
                    inputs:
                      buildType: specific
                      project: $(System.TeamProject)
                      definition: $(System.DefinitionId)
                      buildVersionToDownload: specific
                      pipelineId: ${{ parameters.sourceBuildId }}
                      artifactName: intune-packages
                      targetPath: $(Pipeline.Workspace)/intune-packages

                - task: UseDotNet@2
                  displayName: Install .NET 10 SDK
                  inputs:
                    packageType: sdk
                    version: 10.0.x

                - task: NuGetAuthenticate@1
                  displayName: Authenticate Azure Artifacts

                - pwsh: |
                    & "$(Build.SourcesDirectory)/.azurepipelines/install-relaypublisher.ps1"
                    if ($LASTEXITCODE -ne 0) {
                        exit $LASTEXITCODE
                    }
                  displayName: Install latest relaypublisher from Azure Artifacts
                  env:
                    SYSTEM_ACCESSTOKEN: $(System.AccessToken)
                    SYSTEM_COLLECTIONURI: $(System.CollectionUri)

                - task: AzureCLI@2
                  displayName: Publish to Intune
                  inputs:
                    azureSubscription: $(azureServiceConnection)
                    scriptType: bash
                    scriptLocation: inlineScript
                    inlineScript: |
                      set -euo pipefail
                      manifest_list="$(Pipeline.Workspace)/manifest-list/manifest-list.json"
                      package_dir="$(Pipeline.Workspace)/intune-packages"
                      result_file="$(Build.ArtifactStagingDirectory)/publish-result.json"
                      mkdir -p "$(Build.ArtifactStagingDirectory)"
                      printf '[]\n' > "$result_file"

                      manifest_count="$(jq -r '.manifests | length' "$manifest_list")"
                      if [[ "$manifest_count" == '0' ]]; then
                        echo 'No manifests to publish; producing an empty publish-result artifact.'
                        exit 0
                      fi

                      if [[ -z "${EXPECTED_TENANT_ID:-}" || "$EXPECTED_TENANT_ID" == '$('* ]]; then
                        echo 'EXPECTED_TENANT_ID must be configured as a protected pipeline variable.' >&2
                        exit 1
                      fi

                      if [[ "$BUILD_SOURCEBRANCH" == 'refs/heads/main' &&
                            "$BUILD_REASON" == 'IndividualCI' ]]; then
                        dry_run=false
                      elif [[ "$BUILD_SOURCEBRANCH" == 'refs/heads/main' && "${ALLOW_MANUAL_PUBLISH:-False}" == 'True' ]]; then
                        dry_run=false
                        echo 'Manual run on main with allowManualPublish=true; publishing for real.'
                      else
                        dry_run=true
                        echo 'This is not an automatic main CI build; running publish in dry-run mode.'
                      fi

                      export AZURE_TOKEN_CREDENTIALS=AzureCliCredential
                      args=(publish
                        --repo-root "$(Build.SourcesDirectory)"
                        --manifest-list "$manifest_list"
                        --package-dir "$package_dir"
                        --expected-tenant "$EXPECTED_TENANT_ID"
                        --source-commit "$BUILD_SOURCEVERSION"
                        --result-file "$result_file")
                      if [[ "$dry_run" == true ]]; then
                        args+=(--dry-run)
                      fi

                      relaypublisher "${args[@]}"
                  env:
                    ALLOW_MANUAL_PUBLISH: ${{ parameters.allowManualPublish }}
                    AZURE_TOKEN_CREDENTIALS: AzureCliCredential
                    BUILD_REASON: $(Build.Reason)
                    BUILD_SOURCEBRANCH: $(Build.SourceBranch)
                    BUILD_SOURCEVERSION: $(Build.SourceVersion)
                    EXPECTED_TENANT_ID: $(EXPECTED_TENANT_ID)

                - publish: $(Build.ArtifactStagingDirectory)/publish-result.json
                  displayName: Publish result artifact
                  artifact: publish-result
                  condition: always()

💡 Tip

Publish only the changes: plan compares with the base ref and picks only the changed manifests. So even if I change several packages in separate commits, they are published together in one run.

Dry-run by default: The pipeline publishes for real only on "automatic CI on main" or "a manual run with allowManualPublish=true."

Re-run only Publish: If you put the ID of an earlier run in sourceBuildId, you can publish again without rebuilding the packages.

Approval gate: If you add an approval check to environment: intuneapps-production, someone can review before publishing.

lockBehavior: sequential: This stops two publish runs from running at the same time.

Get relaypublisher inside the CI

You can get relaypublisher in any of these ways. Pick the one that is easiest for you to run.

GitHub artifacts
NuGet (mirroring it to an Azure Artifacts feed is handy)
Homebrew

In the pipeline above, install-relaypublisher.ps1 installs the latest version from Azure Artifacts. Write this script to match the way you get the tool. (Please check the README for the package name and feed name.) I have also submitted it to winget, but it hasn't been accepted yet…

⚠️ Caution
Creating intunewin files (package) only works on Windows. That's why only the Package stage runs on windows-latest. plan / validate / publish also work on Linux, so I use ubuntu for them because it's faster and cheaper.

Merge a PR and test it

Create a branch and add your manifest and scripts.
Open a PR, and build validation runs. Publish runs in dry-run mode, so nothing is registered in Intune. Check the logs to see which app will be assigned to which group.
After the review, merge the PR.
CI runs on main, and after approval, the app is published to Intune.
In the Intune admin center, check the app and its assignments. Then make sure it installs on a test device.
The publish result is saved in the publish-result artifact, which is useful for tracking later.

Summary

The setup takes some time, but once it's done, registering apps in Intune becomes much easier. At home, I don't even want to manage my devices without it anymore. After the first setup, you can add apps just like you do with winget-pkgs. Please give it a try. I'm happy to get feedback on GitHub Issues.

Codex for Visual Studio v0.4.0 / v0.4.1 Released

KAMEGAWA Kazushi — Sat, 17 Oct 2026 10:09:28 +0000

Translation note: The original Japanese article was written by me. This English version was translated with the help of AI.

I've released v0.4.0 and v0.4.1 of Codex for Visual Studio, a Visual Studio extension that lets you use Codex directly from Visual Studio.

Version 0.4.0 contains the main feature additions, while v0.4.1 includes dependency updates and smaller fixes.

Marketplace: https://marketplace.visualstudio.com/items?itemName=KazushiKamegawa.relaytocodexforvs
v0.4.0 Release Notes: https://github.com/kkamegawa/vsextensionforcodex/releases/tag/v0.4.0
v0.4.1 Release Notes: https://github.com/kkamegawa/vsextensionforcodex/releases/tag/v0.4.1

The main changes in this release are:

Improved Goal / Plan mode behavior
Remote Codex App Server support (Experimental)
MXC sandbox support
Updated for Codex CLI 0.162.1
Other bug fixes

1. Improved Goal / Plan Mode Behavior

Previously, when a goal started with /goal was running, the button remained labeled Send, making it impossible to stop execution.

Starting with v0.4.0, the button changes to Stop whenever a goal is active, including between turns during automatic continuation.

When Stop is pressed:

The goal is paused while preserving its objective, budget, and usage.
The latest turn in the thread is interrupted.

Timed-out operations are treated as having an unknown outcome and are not retried automatically, preventing unexpected re-execution.

Plan mode received several related improvements:

Persistent Plan Mode

A checkbox has been added to the composer.

Using /plan also enables it.

Once enabled, Plan mode stays active until explicitly turned off, even if turns complete, fail, or are interrupted. If Codex asks follow-up questions, Plan mode remains active throughout the conversation.

Codex-style Plan Presentation

Suggested plans are displayed as Markdown under "Proposed plan".

When a plan turn finishes, an "Implement this plan?" card appears, allowing you to either:

Proceed with implementation
Continue refining the plan

Experimental API Detection

Plan mode relies on the App Server's experimental collaborationMode field.

Because Codex rejects this field when Experimental APIs are unavailable, the extension now determines availability based on the currently negotiated connection rather than saved settings.

When unsupported:

The Plan checkbox becomes disabled
Entering /plan explains how to enable the feature

One Question at a Time

When multiple questions arrive, they are presented individually using a "Question n of N" workflow.

This also fixes earlier issues where answer choices could become partially hidden.

Stop Works After Questions and Implementation

Fixed an issue where the Stop button stopped working after:

Starting implementation from a plan
Answering a question

Choices Embedded in Text Become Cards

When Codex returns numbered or bulleted choices in normal text, those options are now converted into interactive question cards.

v0.4.1 Goal Confirmation Fix

v0.4.1 fixes an issue where the final goal confirmation message failed to display the Yes/No card if the confirmation text was formatted in bold Markdown.

2. Connect to a Remote Codex App Server (Experimental)

The extension can now connect to an already-running Codex App Server through WebSocket.

This feature is currently marked as Experimental.

The default behavior remains unchanged:

The extension launches codex app-server locally as a child process.
Communication uses stdio.

Internally, the extension still communicates with its local Worker. The Worker decides whether the backend transport should be stdio or WebSocket.

Security and Connection Design

Remote connections require wss
Plain ws is allowed only for loopback (localhost)
Certificate validation cannot be disabled

Authentication uses Bearer tokens.

Profiles store only the path to the token file.

The Worker reads the token during connection establishment, and the token itself is never persisted in configuration files or logs.

Path Mapping

The extension maps:

Local solution root
Remote server root

Path matching is performed component-by-component rather than through string replacement.

For example:

C:\repo

will not match:

C:\repo2

The implementation should also reject paths that escape through symlinks or junctions, although I have not yet fully validated those scenarios.

Connection Isolation

Approvals, caches, and related state are isolated by:

Connection
Account

This prevents leakage between different server connections.

Reconnection Behavior

When a connection drops:

Automatic reconnection is attempted
Draft messages remain in memory
Operations with unknown delivery status are never retried automatically

Separate Commands

Local connections use:

Restart local app-server

Remote connections use:

Reconnect remote app-server

The extension never attempts to stop a remote server.

Setup Guide

I also added:

doc/codex-cli-setup.md
doc/codex-cli-setup_ja.md

The guide covers:

CLI installation
Authentication
Configuration files
Connection target settings
Remote App Server setup
Reconnection
Diagnostics

So far I've only tested loopback connections on the same machine.

I haven't yet validated:

Cross-machine connections
TLS deployments
Cross-platform path translation

If you try those scenarios, I'd love to hear your feedback.

3. MXC Sandbox Support

For local App Server scenarios, you can now choose MXC as the Windows sandbox backend.

The Windows sandbox panel now provides three options:

Option	Setting	Behavior
Follow Codex configuration	None	Uses Codex configuration
Prefer MXC	`-c features.prefer_mxc=true`	Uses MXC when policy permits
Require MXC	`-c windows.sandbox=mxc`	Always uses MXC

Changes take effect the next time the local App Server starts.

Remote profiles are unaffected.

Sandbox Status

The Check sandbox status action shows:

Effective configuration
Policy status

Although it cannot determine which backend executed a specific command.

MXC itself requires no setup.

The elevated/unelevated setup options shown in the UI apply only to the traditional sandbox backends.

MXC Observation

While testing, I noticed that force-terminating only the root Codex process under MXC may leave child processes running.

This does not occur with the unelevated backend.

Since the extension shuts down the entire process tree, users should not encounter this issue during normal use.

4. Updated for Codex CLI 0.162.1

Communication with the App Server has been updated for compatibility with Codex CLI 0.162.1.

Because some remote servers may still use older versions, I continue to keep 0.159.1 available for regression testing.

Extension ↔ Worker Protocol Updates

The protocol version between the extension and Worker has also been updated.

Version 23 introduces:

Experimental API status reporting

which enables the new Plan mode availability checks.

MXC support adds protocol version 24.

Unsupported combinations fail safely rather than attempting to continue with incompatible behavior.

Additional 0.162.1-related changes include:

Goal operations now send origin: "user" for proper authorization handling
MCP OAuth completion is matched using loginId
Skill paths are now treated as server-provided identifiers rather than requiring absolute paths

5. Other Notable Fixes

Fixed a banner that failed to disappear after successful manual reconnection
Fixed a state where loading a remote token could leave the UI stuck at "Connecting / Checking account"
Improved readability of question cards in dark themes by using Visual Studio theme resources
Added an MCP details toggle to collapse MCP server information
Missing or unreadable attachments now cause send operations to fail instead of being silently skipped
v0.4.1 updates NuGet dependencies, including MessagePack packages affected by a published vulnerability

Closing Thoughts

This release primarily focuses on improving Goal and Plan mode usability while laying the groundwork for remote connectivity.

Remote App Server support is still experimental, so please file an issue if you encounter problems.

To install:

Download Codex.VisualStudio.Extension.vsix from GitHub Releases and double-click it, or
Install directly from the Visual Studio Marketplace

Visual Studio 17.14 or later is required.

What's Next?

After .NET 8 reaches end-of-support, I plan to fully migrate the extension to .NET 10.

At that point, Visual Studio 2026 or later will be required.

I Built RelayPublisher: A winget-like Publishing Workflow for Microsoft Intune

KAMEGAWA Kazushi — Tue, 01 Sep 2026 05:09:19 +0000

Note about this article

The original version of this article was written entirely by me in Japanese.

I used AI to translate and polish the English version for a global audience, but the ideas, design decisions, implementation details, and original content are all my own work.

If you'd like to read the original Japanese article, you can find it here:

https://kkamegawa.hatenablog.jp/entry/2026/08/30/220813

Managing Intune Apps as Code with RelayPublisher

Managing custom applications in Microsoft Intune has always felt more complicated than it should be.

When you need to publish an internal application, you typically have a few options:

Register it manually through the Intune portal
Use one of the sample PowerShell scripts available online
Build your own automation around Microsoft Graph APIs

All of these approaches work, but none of them feel particularly developer-friendly.

In my case, the process was even more frustrating because I normally don't operate with elevated privileges. Every time I needed to publish or update an application, I had to perform a PIM elevation before making changes.

That led me to a simple question:

Why can't Intune application publishing work more like winget?

I wanted a workflow where application definitions could live in source control, be described in YAML, and be published automatically through CI/CD.

That idea became RelayPublisher.

kkamegawa / Relaypublisher

Relaypublisher

Relaypublisher publishes winget-like YAML manifests as Microsoft Intune LOB apps from CI.

Distribution:

NuGet global tool package id: relaypublisher
Command name: relaypublisher
Package version: injected by CI from Git tag vX.Y.Z
Feeds: nuget.org, GitHub Packages (this repository), and Azure Artifacts
Self-contained single-file apps for win-x64, win-arm64, and osx-arm64 are attached to each GitHub release. They are neither code-signed nor notarized, so macOS shows a Gatekeeper warning.

Quick install:

dotnet tool install --global relaypublisher

See doc/05-operation.md for installing from GitHub Packages or Azure Artifacts instead.

The repository now contains the .NET CLI foundation for the normal workflow:

validate checks manifest schema rules and repository-wide identity uniqueness.
plan resolves the target manifest set once and writes manifest-list.json for later CI jobs.
package stages app files: Windows Win32 .intunewin packages (Windows runner required) or a staged, checksum-verified macOS .pkg (any OS).
publish creates or updates Intune apps, uploads packaged content…

View on GitHub

What is RelayPublisher?

RelayPublisher is an open-source tool that allows you to define Intune applications using YAML and publish them through automation.

Instead of clicking through the Intune portal, you manage application definitions as code.

If you're already familiar with Infrastructure as Code (IaC) or GitOps practices, the concept should feel natural.

Why I Built It

Historically, building this type of tool felt like a lot of work.

There are many moving parts:

Microsoft Graph integration
Intune packaging
Authentication
Configuration management
Error handling

The emergence of generative AI significantly reduced the effort required to create and maintain a project like this. Tasks that would previously have been tedious became much easier to implement.

As a result, I was finally able to build the tool I had wanted for a long time.

Key Features

YAML-based application definitions
CI/CD-friendly workflow
Microsoft Intune integration
Source-controlled application management
Support for GitHub and Azure Repos workflows

A sample YAML definition is included in the repository to help you get started quickly.

Example:


SchemaVersion: "1.0"
PackageIdentifier: Microsoft.PowerShell
PackageName: PowerShell
Developer: Microsoft Corporation
Publisher: Microsoft Corporation
Description: PowerShell 7 cross-platform automation and configuration tool.
PackageVersion: 7.6.5
AssignmentSync: merge

Apps:
  - Platform: macos
    Architecture: arm64
    InstallerType: pkg
    # pkg (default): unmanaged macOSPkgApp, unsigned allowed, up to 8 GB, and the
    # only AppType that can target MinimumOSVersion 14+ (v14_0/v15_0 are beta-only
    # flags; see doc/01-manifest-schema.md 5.7 and MacOsMinimumOperatingSystemTable).
    AppType: pkg
    DisplayName: PowerShell [macOS ARM64]

    # Single Source item for macOS (unified source item shape, doc/01-manifest-schema.md 5.0.1).
    # PowerShell/PowerShell is a public repository, so Auth.Type: none is enough
    # for anonymous asset download.
    Source:
      Type: githubRelease
      Owner: PowerShell
      Repository: PowerShell
      Tag: v7.6.5
      AssetName: powershell-7.6.5-osx-arm64.pkg
      Destination: powershell-7.6.5-osx-arm64.pkg
      Sha256: "6ea58f4e91ab2df133ac18a42e291e4e870a623e3c5ab6f8368259cd9ac22770"
      Auth:
        Type: none

    Requirements:
      # PowerShell 7.6 (LTS) supports macOS 14 (Sonoma), 15 (Sequoia), and 26 (Tahoe).
      # 14.0 is the lowest version Relaypublisher's version table can map (26.0 is not
      # yet defined there); AppType: pkg allows the beta-only v14_0 flag.
      MinimumOSVersion: "15.0"

    Detection:
      IgnoreAppVersion: false
      IncludedApps:
        - BundleId: com.microsoft.powershell
          BundleVersion: 7.6.5

    # Optional, AppType: pkg only (doc/01-manifest-schema.md §5.4.2): pre/post-install
    # shell scripts, mapped to Graph macOSPkgApp.preInstallScript/postInstallScript.
    # Paths are relative to --repo-root (samples/, per this file's own README).
    Scripts:
      PreInstall: scripts/macos/powershell/preinstall.sh
      PostInstall: scripts/macos/powershell/postinstall.sh

    # Left empty so this manifest applies unmodified in any tenant. Add your own
    # target group(s) before a real (non-dry-run) publish, for example:
    # Assignments:
    #   - Target: group
    #     GroupId: "<your-assignment-group-guid>"
    #     Intent: required
    Assignments: []

Visual Studio 2022 Memory Eater Extension

KAMEGAWA Kazushi — Fri, 18 Jun 2021 11:19:02 +0000

I had just published simple extension for Visual Studio 2022 Preview 1.

GitHub/kkamegawa/memoryeaterextension

This extension will not publish to marketplace.

It's simple memory eater extension :-).