DEV Community: KAMEGAWA Kazushi

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 :-).