Hobbyist CNCDan is trying to build a real-world version of Windows' classic 3D Pinball for Windows -- Space Cadet, using 3D-printed flippers, bumpers, LEDs, slingshots, and a raised playfield modeled after the original virtual table. But in bringing the digital table into the real world, CNCDan has already run into several physical challenges the software never had to contend with... Ars Technica reports: After scaling and skewing the on-screen, perspective-shifted view of the Space Cadet playfield onto a 1-meter-tall table, he ended up with a rectangular playfield just 56 cm wide. That's on the smaller side for commercial pinball tables and maps to playfield bumpers that are just 53 mm wide -- way smaller than any prebuilt bumpers that are commercially available.
Once CNCDan dealt with issues with unreliable plastic microswitches for those tiny bumpers (Hall effect magnets seemed to help), he ran into a separate problem with the even smaller bumpers on the raised playfield. The wiring for those bumpers had to be arranged very carefully to avoid blocking a kickback return alley underneath, a positioning problem that the original designers of the virtual table didn't have to consider at all. CNCDan also ended up adding a physical mechanism to simulate the short delay 3D Space Cadet players may remember, when the ball dropped down a hole from the raised playfield back to the flippers below.
CNCDan says he's currently looking for artists to help him with a hand-drawn re-creation of the original Space Cadet playfield, which he doesn't want to use AI for. "I'm sure [AI] can do it, but I'd much rather give this job to a real human being," he said in the video.
Microsoft Defender Experts identified an active cryptojacking campaign in which malicious download sites are surfaced not only through traditional search engine poisoning, but also through AI chatbot interactions. This emerging delivery technique extends social engineering beyond conventional search results and increases the visibility of malicious software recommendations.
The campaign impersonates trusted system utilities including CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, and PDFgear to target users likely to own high-performance GPUs. Rather than maximizing infection volume, the threat actor appears focused on compromising systems with higher mining value.
Beyond cryptocurrency mining, the campaign establishes persistent remote access through abused ScreenConnect deployments that could later support data theft, lateral movement, or ransomware activity. This combination of AI-assisted delivery, software impersonation, and persistent access highlights how threat actors are adapting social engineering and monetization strategies to modern user behavior.
Microsoft Defender detected and blocked activity associated with this campaign. Organizations should enable cloud-delivered protection, run EDR in block mode, and enable attack surface reduction rules to reduce risk.
Attack chain overview
Cryptocurrency mining campaigns have long favored volume over precision, compromising as many hosts as possible to extract marginal value from each. The campaign described in this blog takes a more deliberate approach: its operators have built a targeting and monetization strategy engineered from the ground up to maximize GPU mining yield per compromised device.
Initial access
The campaign begins when users search for common system utility and hardware-monitoring software on a search engine. The users are then presented with manipulated results that direct them to attacker-controlled lookalike sites. The operator runs a coordinated SEO poisoning operation that simultaneously masquerades as a broad portfolio of trusted utility brands, where each one serves the same downstream payload chain.
The campaign abuses multiple trusted brands, including: CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, and PDFgear. The selection of these brands is deliberate. Each application is favored by PC enthusiasts and hardware-focused users, precisely the audience most likely to own a high-performance discrete GPU, the hardware that makes GPU cryptocurrency mining economically viable.
Screenshot of search engine results showing a malicious source of hwmonitor.
In April 2026, we observed reports indicating that users may have been directed to malicious domains through interactions with large language model (LLM)–based tools. In these cases, users querying AI chatbots for software download recommendations were presented with links to attacker‑controlled domains within generated responses. Analysis of VirusTotal scan associated with these domains further identified traffic metadata referencing chatbot interactions as a potential referral context.
While this behavior is based on observed patterns and correlated data sources, it’s consistent with emerging techniques in AI search result poisoning, representing an extension of traditional SEO poisoning beyond conventional search engines.
VirusTotal scan results showing traffic metadata associated with attacker-controlled domains, corroborating observed AI-assisted delivery patterns in this campaign.Example of an LLM-generated response observed to contain links to domains later identified as malicious and associated with this campaign. This example is illustrative and does not indicate a systemic issue with any specific AI service.
Each fake site presents a download button that claims it has the legitimate utility. The download instead retrieves a ZIP archive hosted on a campaign‑specific subdomain of gleeze.com. The gleeze.com parent domain is hosted by infrastructure associated with Dynu (dynu.com), a dynamic DNS provider frequently leveraged by threat actors.
Since March 2026, we’ve identified more than 150 malicious domains that we assess serve these malicious tools, masqueraded as system utilities linked to this campaign.
DLL sideloading and silent installation of ScreenConnect software
The downloaded ZIP archive contains the legitimate executable for the spoofed utility alongside a malicious DLL named autorun.dll. When the user launches the executable, the legitimate program loads autorun.dll from the same folder via DLL sideloading, a technique that requires no exploitation and generates no user-visible anomaly. Analysis revealed nine distinct autorun.dll variants across the campaign.
Files dropped after extraction of the ZIP file after download.
The malicious DLL uses msiexec.exe to silently install a second malicious DLL named vcredist_x64.dll, named to masquerade as the Visual C++ Redistributable. This file is itself a packaged installer for ScreenConnect software.
ScreenConnect software (also known as ConnectWise Control) is a legitimate commercial remote management tool widely used by IT administrators. The tool itself is not at fault; rather, the threat actor abuses its legitimate capabilities to establish persistent remote access consistent with a broader pattern of remote monitoring and management (RMM) tool abuse observed across the threat landscape
Once installed, the ScreenConnect client constantly attempts to communicate with the attacker-controlled server at 193.42.11[.]108 via the following service invocation:
The h parameter (directdownload[.]icu) is the host the client connects to.
The repeated c= parameters are ScreenConnect’s custom property fields, which in some cases closely matched the software used to drop ScreenConnect. However, across other instances we were unable to verify if this is an identifier linked to the software used via SEO poisoning.
Execution
SimpleRunPE dropper and process hollowing
Once the ScreenConnect session is established, the attacker drops a binary named SimpleRunPE.exe directly via ScreenConnect’s file-transfer feature.
Project lineage
Static analysis of this binary surfaced an embedded Program Database (PDB) path inside the binary’s debug directory:
The folder structure in the path matches a public proof-of-concept repository on GitHub (Watermwo/Simple-RunPE-Process-Hollowing), with a -RUNPE suffix. With this information, Microsoft assesses with moderate confidence that the dropped binary’s process hollowing might be a fork of this public codebase. Using this PDB path as a pivot, we identified multiple binaries sharing similar debug paths, all reported to the Microsoft Defender team and addressed.
Screenshots showing Similarities between repo and the malicious binary observed in this campaign.
Install path and the alternative PowerShell delivery
Once executed, SimpleRunPE.exe writes a copy of itself into a hidden install folder as RuntimeHost.exe. The install folder name uses the campaign identifier D3F4E2A1, which recurs throughout the malware as a mutex name (Global\D3F4E2A1_Svc) and in Defender exclusion entries.
The malware sets the Hidden and System file attributes on both the install folder and the RuntimeHost.exe file, hiding them from default Explorer views. The malware first attempts to install into a preferred location resolved at runtime and falls back to %LocalAppData%\Microsoft\Windows\Caches\D3F4E2A1\ if the preferred location is not writable.
In a subset of compromises, rather than dropping SimpleRunPE.exe directly via ScreenConnect file transfer, a malicious PowerShell script that fetched the binary from a remote drive, stored it locally as vlc.exe, and created a one-time scheduled task to execute and then delete itself, reducing forensic traceability.
PowerShell script dropped by attacker over ScreenConnect.
Persistence
Once SimpleRunPE.exe has copied itself to the install path as RuntimeHost.exe, it establishes six persistence mechanisms across multiple Windows autostart locations. The persistence mechanisms span three scheduled tasks, two registry Run keys, and one Startup folder shortcut.
Suspicious persistence methods implemented by malware.
Each time the persistence mechanism executes, it relaunches RuntimeHost.exe, which functions as a recovery mechanism for the follow up process hollowing behaviour. Each time the persistence mechanism launches RunTimeHost, it validates whether the following behavior is complete. If the behavior isn’t complete, the rumtimehost.exe attempts to hollow as well.
Defense evasion
Process hollowing into Microsoft-signed .NET binaries
The malware simplerunpe.exe proceeds to attempt process hollowing into a legitimate Microsoft-signed binary. The malware carries a hardcoded list of seven candidate target processes, all of them legitimate Windows utilities that ship with the .NET Framework. These targets are tried in order, and the first one whose binary is present on the host’s disk is selected:
InstallUtil.exe
RegAsm.exe
RegSvcs.exe
MSBuild.exe
AppLaunch.exe
AddInProcess.exe
aspnet_compiler.exe
Targets for process injection.
The dropper launches the chosen target binary in a suspended state and uses API calls such as WriteProcessMemory, SetThreadContext, ResumeThread to hollow the process. This causes the malicious mining code to run under the identity of a trusted Microsoft-signed binary and execute its own code.
Process hollowing attempt by malware.
Defender exclusions
The malware simplerunpe.exe invokes PowerShell to call the Add-MpPreference cmdlet, registering both path-based and process-based exclusions.
SecurityHealthHost.exe, RuntimeHost.exe, lolMiner.exe, SRBMiner-MULTI.exe, miner.exe, and gminer.exe
Target Processes for Defender AV exclusions.
Anti-analysis check
The malware performs anti-analysis checks, exiting silently if any indicator suggests the binary is running in an analysis environment.
The malware checks for virtual machine detection: (registry keys for VMware Tools and VirtualBox Guest Additions, the SCSI Identifier value checked against VBOX/VMWARE/QEMU substrings, MAC address prefix matching against known virtualization vendor ranges, and WMI queries against Win32_ComputerSystem and Win32_BIOS.
The malware also checks against a hardcoded list of forty analyst-tool process names spanning debuggers, disassemblers, decompilers, PE inspection tools, and network analysis utilities, including dnSpy, x64dbg, IDA, Ghidra, ProcMon, Wireshark, Fiddler.
If any of the binaries are detected, the process terminates its execution.
Screenshot showing Anti Analysis/Anti VM implementation by malware
Custom crypto mining loader
Once process hollowing is complete and the malware is running inside a Microsoft-signed Windows utility, the mining-client portion of the binary takes over. The first action is to acquire a system-wide mutex named Global\D3F4E2A1_Svc. The mutex name uses the same campaign identifier (D3F4E2A1) as the install-path directory and the Defender exclusion paths.
RuntimeHost.exe probes this mutex to confirm that hollowing has already succeeded and the hollowed process is still alive on the host.
Host-based reconnaissance
The hollowed binary establishes a connection to the attacker’s server (described in the next section) and sends a registration frame containing comprehensive host reconnaissance to the attacker controlled C2/panel.
Category
What’s collected
Fingerprinting
CPU model and core count; GPU model and vendor with integrated vs. discrete classification; total physical RAM; device type.
Live resource state
Current CPU usage; current GPU usage (separately for total and dedicated GPU); GPU temperature; system uptime.
Operating system
Windows version and architecture, full Windows product name, whether the malware is running with administrative privileges.
Network identity
Local IP address; country code derived from an outbound geolocation lookup.
Security posture
Installed antivirus product enumerated via Windows Security Center.
User activity
Idle seconds (time since last keyboard or mouse input).
GPU activity detection
Detection of gaming, streaming, or other GPU-heavy user activity based on sustained GPU usage.
Mining state
Whether the miner process is currently running; current latency to the mining pool.
Screenshot showing Host reconnaissance performed by binary after process hollowing
Command and control encrypted address and certificate pinning
The address of the attacker’s server is held inside an encrypted blob using AES-128-CBC encryption. In addition to obfuscating the address, we observed a hard-coded Transport Layer Security (TLS) certificate.
Screen showing encrypted C2 domain and certificate hard coded in binary.
Decrypting the embedded blob yields the C2 URL wss[:]//minemine.gleeze[.]com:8443/ws.
The malware also hardcodes the SHA-256 fingerprint of the TLS certificate expected at this endpoint, used to pin the connection during the WebSocket handshake:
The malware (hollowed Windows binary) doesn’t embed a miner program. Instead, when it’s time to begin mining, the malware downloads the appropriate miner archive at runtime and runs it. Three miner programs are supported: gminer, lolMiner, and SRBMiner-MULTI, all of which are GPU-focused tools.
Auto-repair persistence and activity tracking
The hollowed binary also runs a continuous background routine that wakes every five seconds and checks whether mining should currently be paused (based on the GPU-activity gate), and whether all six persistence mechanisms are still in place.
When the verification cycle runs, the malware
Checks each of the three scheduled tasks by invoking schtasks.exe /query /tn “<task name>” and recreates any task whose query returns a non-zero exit code.
Checks each of the two registry Run keys via direct registry reads and rewrites missing or modified entries.
Checks the Startup folder shortcut by file existence and recreates it if missing.
Re-runs the Defender exclusion registration on every cycle, ensuring any exclusions that were removed are restored.
Apart from verifying the persistence, the malware also tracks the process activity on the device. As soon as the loader detects the following processes as running, it terminates the miner process.
User activity monitoring/ terminate miner when above processes are detected.
The malware also monitors GPU usage and terminates its activity. If the GPU usage is high or the device isn’t idle, the mining processes are terminated.
Certificate pivoting
As mentioned previously, using this hard-coded certificate, we identified 3 IPs using this specific TLS certificate.
Using OSINT, this TLS certificate was observed to be presented by 3 IP addresses. Microsoft assesses that these IPs are part of the C2 infrastructure.
• 93.115[.]10.35
• 198.23[.]185.238
• 2.59.132[.]106
Using these IPs as pivots, we observed that there were additional linked campaigns using a similar DynamicDNS domain giize[.]com. Some of the sources of the malicious file downloads in these campaigns originated from:
Direct-download[.]giize[.]com
Free-download[.]giize[.]com
These domains are also linked to a series of malicious domains performing similar SEO poisoning-based campaigns, leading to same infection chain described in this blog.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.
Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:
Turn on web protection in Microsoft Defender for Endpoint.
Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
Remind employees that enterprise or workplace credentials should not be stored in browsers or password vaults secured with personal credentials. Organizations can turn off password syncing in browser on managed devices using Group Policy.
Block executable files from running unless they meet a prevalence, age, or trusted list criterion(GUID: 01443614-cd74-433a-b99e-2ecdc07bfc25)
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Tactic
Observed activity
Microsoft Defender coverage
Execution
Unusual ScreenConnect service creation activity
Suspicious service launched (endpoint detection and response – EDR)
Malicious DLL sideloading linked to autorun.dll
An executable file loaded an unexpected DLL file (EDR)
ScreenConnect Installation activity
Suspicious behaviour by msiexec.exe (EDR)
Defender detection of crypto mining framework binary
Trojan:MSIL/CoinMiner!MS(AV)
MDAV detection of suspicious DLL
HackTool:Win64/Malgent!MSR(AV)
Persistence
Scheduled task creation activity associated with malicious binary
Suspicious Task Scheduler activity
Malicious ASEP linked with malicious binary execution
Anomaly detected in ASEP registry
Suspicious .LNK file in startup folder
An uncommon file was created and added to startup folder
Defense Evasion
Antivirus exclusion added by malicious binary
Suspicious Defender Antivirus exclusion Modification attempt in Microsoft Defender Antivirus exclusion listAn uncommon file was created and added to startup folder
Process hollowing activity to malicious binary
A process was injected with potentially malicious code
Command and control
Attacker executing malicious commands via ScreenConnect
Suspicious command execution via ScreenConnect
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:
Incident investigation
Microsoft User analysis
Threat actor profile
Threat Intelligence 360 report based on MDTI article
Vulnerability impact assessment
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender or Microsoft Sentinel.
Advanced hunting
Suspicious binary execution from unusual directory
This query searches for suspicious RunTimeHost.exe from a specific directory. Executions from this directory are often linked to the relevant campaign.
//
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "RuntimeHost.exe"
or InitiatingProcessFileName =~ "RuntimeHost.exe"
| where (FolderPath has @"\Caches\D3F4E2A1")
or (InitiatingProcessFolderPath has @"\Caches\D3F4E2A1")
| project Timestamp, DeviceId, DeviceName,
FileName, FolderPath, ProcessCommandLine,
ParentProcess = InitiatingProcessFileName,
ParentProcessPath = InitiatingProcessFolderPath,
ParentProcessCmd = InitiatingProcessCommandLine,
AccountName
Suspicious scheduled task creation activity
This query looks for suspicious scheduled task creation activity with task names often associated with this cryptojacking campaign.
//Run the below query to identify events linked to the suspicious scheduled task creation activity
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine has "/create"
| where ProcessCommandLine has_any (
"Windows System Health Monitor",
"Windows System Health"
)
| project Timestamp, DeviceId, DeviceName,
AccountName,
TaskCreationCmd = ProcessCommandLine,
ParentProcess = InitiatingProcessFileName,
ParentProcessPath = InitiatingProcessFolderPath,
ParentProcessCmd = InitiatingProcessCommandLine
Suspicious MSIEXEC activity associated with a binary loading a suspicious DLL
This query looks for a process loading a suspicious DLL named ‘autorun.dll’ followed by unusual MSIEXEC activity from the same binary.
let SideloadingProcesses =
DeviceImageLoadEvents
| where Timestamp > ago(60d)
| where FileName =~ "autorun.dll"
| where InitiatingProcessFolderPath has_any (
@"\Downloads\", @"\AppData\Local\Temp\", @"\AppData\Roaming\",
@"\ProgramData\", @"\Users\Public\",@"\Desktop\"
)
|where FolderPath has @"\sources\"
| project SideloadTime = Timestamp, DeviceId, DeviceName,
LauncherProcessId = InitiatingProcessId,
LauncherCreationTime = InitiatingProcessCreationTime,
LauncherName = InitiatingProcessFileName,
LauncherPath = InitiatingProcessFolderPath,
SideloadedDllPath = FolderPath;
let unique_devices=SideloadingProcesses|distinct DeviceId;
let MsiSpawns =
DeviceProcessEvents
| where Timestamp > ago(60d)
|where DeviceId in(unique_devices)
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine has "/i"
| where ProcessCommandLine has "/quiet"
| project MsiSpawnTime = Timestamp, DeviceId,
LauncherProcessId = InitiatingProcessId,
LauncherCreationTime = InitiatingProcessCreationTime,
MsiCmd = ProcessCommandLine,
MsiProcessId = ProcessId ;
SideloadingProcesses
| join kind=inner MsiSpawns
on DeviceId, LauncherProcessId, LauncherCreationTime
| where MsiSpawnTime between (SideloadTime .. (SideloadTime + 30m))
| project SideloadTime, MsiSpawnTime,
DeviceId, DeviceName,
LauncherName, LauncherPath, LauncherProcessId,
SideloadedDllPath, MsiCmd, MsiProcessId
This research is provided by Microsoft Defender Security Research with contributions from Parasharan Raghavan and members of Microsoft Threat Intelligence.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
Nine months ago I sat down with ChatGPT to upgrade the command routing and keybinding system for Terminal.Gui. I expected magic. What I got was C# that would have compiled cleanly in 2007. Static singletons. Obsolete event handlers. APIs we’d deprecated two years ago. The agent was confident, fast, and clinically insane.
I had a choice. Get mad at the agent, or get to work.
This is the choice every library maintainer faces in the new AI world. Models are trained on whatever code is in the world, which means they know your v1 better than they know your v2. They are not going to politely wait for your docs to catch up. They are going to ship code, with or without you.
So either you build for them, or they build against you.
In the past month, in an effort to take advantage of Copilot’s insane pricing model that is going away next week, I took on several ambitious Terminal.Gui projects. This time the experience approached magic (with a lingering whiff of Mad Hatter).
What “agent-friendly” actually means
Agent-friendly software treats AI agents as first-class consumers of every artifact the project produces: APIs, docs, CLIs, demos, and tests.
Most people, when they say “I made my codebase AI-friendly,” mean “I added a CLAUDE.md.” That is the bare minimum, and it does almost nothing on its own.
The actual work is five things.
Typed contracts at every edge. JSON in, JSON out, with a schemaVersion. POSIX exit codes. Timeouts. Errors that say what’s wrong in a shape the agent can parse.
Documentation organized by reader. Humans get tutorials. Agents get schemas, runbooks, and machine-readable summaries. Same source of truth, different surface area.
Anti-pattern files, not just pattern files. The model already knows your v1 API. The fight is teaching it you have a v2.
Reproducibility. If a human can run your demo and watch it work, an agent should run the same demo and verify it worked, headlessly, in CI.
Agent-readable specs. Hand the agent a phased plan with decision records and scope boundaries, not “go figure it out.” The library being agent-friendly is necessary. The task being agent-friendly is the other half.
None of this is new. It is the boring discipline of writing a good API, applied to a population of consumers that didn’t exist three years ago.
Here is what came out of taking that seriously across the Terminal.Gui ecosystem.
Terminal.Gui v2
v2.0 Released in April. The architectural headline was real: we killed the static singleton, moved to instance-based IApplication, built a pure-ANSI driver, and rebuilt mouse and keyboard from the parser up.
The headline for agents is different. The API is now boring enough that an LLM can use it correctly. Singletons make models hallucinate state. Instance-based APIs do not. Type-safe dialogs make models invent fewer fields. Pure ANSI means one driver to reason about across platforms, not three.
We also did the unglamorous work. Rewrote AGENTS.md as a real payload instead of a pointer. Shipped a v1-to-v2 corrections file so agents stop generating obsolete API calls. Added llms.txt to the docs site. Wrote a CLAUDE.md tuned for Claude Code specifically. The migration guide is now the kind of document you can point an agent at and say “port my v1 app,” and it works. I’ve done it.
Last week Copilot (using GPT 5.5) did something to Terminal.Gui that would have been a month of typing in 2024. PR #5411 refactors ConfigurationManager to be based on Microsoft.Extensions.Configuration. 86 files, 14 commits, six phases, 17,110 tests still passing. I didn’t write any of it.
It wasn’t a one-shot. The first pass invented APIs that didn’t exist (Driver.ForceMaxColors, fake theme names, properties that were renamed two versions ago). I caught it, made Copilot verify every API reference against the actual codebase, and from there it was clean.
The real magic wasn’t the agent. It was the spec. Six phases, decision records (D-01, D-02) for the contested design choices, scope-in and scope-out called out explicitly, a stacked follow-up PR planned before this one shipped. I used Opus 4.7 to help write the spec. Copilot and GPT 5.5 executed it. That is the division of labor that works.
If an agent can’t use your library well, your library has bad ergonomics. Agents do not read between the lines.
Editor
Terminal.Gui.Editor is what happens when you take AvaloniaEdit’s document layer, port the pure-data bits to a TG View, and ship it as a NuGet package. It is a library. It is not a competitor to vim.
That said, the ted example app is a great TUI text and code editor!
The README lists the use cases: a script box, a config pane, a notes view, a chat composer. And one more, named explicitly because it matters: the input area of an LLM agent’s terminal front-end.
Building a TUI for an agent? You need a multi-caret, undo-aware, syntax-highlighted edit surface. That is now a dotnet add package away.
A clet is a CLI-let: a single subcommand that delivers a typed, schema-versioned interactive prompt to either a human or an agent, with the contract negotiated by a single --json flag.
One binary, eighteen subcommands, every one a typed prompt. edit, select, pick-file, confirm, date, color, multi-select. For a human, a rich TUI. For an agent:
JSON envelope. Schema version. POSIX exit codes (0 ok, 2 usage, 130 cancelled). --timeout 30s so an agent script doesn’t hang on a missing human. Same binary serves the shell user picking a deploy target and the agent escalating a decision before continuing.
That is what agent-friendly looks like at the contract level. A typed result with a parseable error path. Not a markdown file.
The competition is gum, fzf, dialog, and whiptail. Each is good at one thing. clet is the unification, with a real UI toolkit underneath and a JSON contract on top so the agent never has to scrape stdout.
cli
gui-cs/cli generalizes the clet idea. It is a Terminal.Gui library that lets your app expose its Views as scriptable CLI commands with typed JSON output, POSIX exit codes, and AI-agent discoverability.
Build an interactive TUI for humans. Get a scriptable agent surface for free. Same View, two front ends.
Still early. The shape is right.
tuirec
tuirec records a terminal app driven by a keystroke script and produces an animated GIF. Cross-platform, Go, agg-backed.
What I am proud of is the README’s For AI Agents section. Three layers, each doing a different job.
OpenCLI handles discovery. tuirec opencli returns a machine-readable command schema. The agent learns what commands and flags exist.
Agent guide handles semantics. tuirec agent-guide explains keystroke syntax, timing budgets, and platform gotchas. The agent learns how to use the commands correctly.
Recipe files handle runbooks. Markdown the agent follows verbatim for a specific recording.
Discovery, then semantics, then runbook. Three different decisions the agent has to make, three different documents serving each one. Ship only the first and the agent guesses. Ship all three and the agent succeeds on the first try.
“Record UICatalog opening the About dialog, hovering over each tab, and quitting” should be an agent call, not a human afternoon.
As of today, Terminal.Gui’s API docs for each View shows a GIF illustrating what the View looks like in action.
Spectre excels at beautiful output: tables, charts, trees, panels, figlet, rich markup. Terminal.Gui excels at interactive TUI apps: forms, focus, layout, lifecycle. These are complementary, not competitors. We have built a first pass at the bridge, a read-only TG View that renders any Spectre IRenderable inline alongside interactive TG controls.
The argument I led with in the issue is the one I want to repeat here:
Increasingly, it’s AI agents (not just developers) generating TUI code. They shouldn’t have to choose between the two libraries when both are in their training data.
That is a new design constraint, and a permanent one. Your library’s documentation in 2026 is partly shaped by which other libraries the model has also memorized. Some of your consumers have weights.
So who is the overlord here?
Not them. Still us.
But the people who treat agents as adversaries to defend against are going to ship software that fights its own tooling. The people who treat agents as users to design for are going to ship software that gets better every time the models do.
Every contract typed. Every doc dual-audience. Every demo agent-reproducible. Five projects that work for humans, work for agents, and work better because I stopped pretending those were different requirements.
And just wait until you see what I am going to do next with WinPrint 2.x. Humans have stopped printing stuff. Maybe agents will want to instead.
Imagine you are building your company’s RAG chat application using Azure OpenAI Service and orchestrating the flow with LangChain. The chat experience works, but now it needs to be grounded in your company’s data. You generate embeddings and want to store and query them without adding another database or complex sync pipeline. Instead of stitching services together, you use Azure DocumentDB (with MongoDB compatibility) with built-in vector search to store your JSON data and embeddings in one place. You deploy the app to Azure App Service and quickly compare vector search alone versus a full RAG pipeline, sharing it with your team for testing.
What will you learn?
In this blog, you'll learn to:
Create an Azure DocumentDB (with MongoDB compatibility) resource.
Create an embeddings and a chat deployment in Azure Foundry portal.
Create an Azure App service website with Continuous deployment from GitHub.
Configure Azure App service application settings to enable communication between Azure resources.
Configure GitHub workflow to work successfully.
What is the main objective?
Build AI Powered RAG Application using the LangChain, Azure OpenAI, and Azure DocumentDB (with MongoDB compatibility): Step-by-Step Guide
Prerequisites
An Azure subscription.
If you don’t already have one, you can sign up for an Azure free account.
For students, you can use the free Azure for Students offer which doesn’t require a credit card only your school email.
A GitHub Account.
Summary of the steps:
Step 1: Create an Azure DocumentDB (with MongoDB compatibility) resource
Step 2: Create an Azure OpenAI resource and Deploy chat and embedding Models
Step 3: Create an Azure App Service and Deploy the RAG Chat Application
Step 1: Create an Azure Cosmos DB for MongoDB vCore Cluster
In this step, you'll:
Open the Azure Portal.
Create an Azure Cosmos DB for MongoDB vCore Cluster.
Create a new Azure DocumentDB (with MongoDB compatibility) resource
In this step, you create an Azure Cosmos DB for MongoDB vCore Cluster to store your data, vector embedding, and perform vector search.
1. Type mongodb vcore in the search bar at the top of the portal page and select Azure Cosmos DB for MongoDB (vCore) from the available options.
2. Select Create from the toolbar to start provisioning your new cluster.
3. Add the following information to create a resource:
What
Value
Subscription
Use your preferred subscription. It's advised to use the same subscription across all the resources that communicate with each other on Azure.
Resource group
Select Create new to create a new resource group. Enter a unique name for the resource group.
Cluster name
Enter a globally unique name.
Location
Select a region close to you for the best response time. For example, Select UK South.
MongoDB version
Select the latest available version of MongoDB.
4. Select Configure to configure your cluster tier.
5. Add the following information to configure the cluster tier. You can scale it up later:
What
Value
Cluster tier
Select M25 tier, 2 (Burstable) vCores.
Storage
Select 32 GiB.
6. Select Save.
7. Enter the cluster AdminUsername and Password and store them in a secure location.
8. Select Next to configure the networking settings.
9. Select Allow Public Access from Azure services and resources within the Azure to this cluster.
10. Select Add current IP address to the firewall rules to allow local access to the cluster.
11. Select Review + create.
12. Confirm your configuration settings and select Create to start provisioning the resource.
Note: The cluster creation can take up to 10 minutes. It's recommended to move on with the rest of the steps and get back to it later.
Step 2: Create an Azure OpenAI resource and Deploy chat and embedding Models
In this step, you'll:
Create an Azure OpenAI resource.
Create chat and embedding model deployments.
Create an Azure OpenAI resource
In this step, you create an Azure OpenAI Service resource that enables you to interact with different large language models (LLMs).
1. Type openai in the search bar at the top of the portal page and select Azure OpenAI from the available options.
2. Select Create from the toolbar to provision a new OpenAI resource.
3. Add the following information to create a resource:
What
Value
Subscription
Use the same subscription you used to apply for Azure OpenAI access.
Resource group
Use the resource group you created in the previous step.
Region
Select a region close to you for the best response time. For example, Select UK South.
Name
Enter a globally unique name.
Pricing tier
Select S0. Currently, this is the only available pricing tier.
4. Now that the basic information is added, select Next to confirm your details and proceed to the next page.
5. Select Next to confirm your network details.
6. Select Next to confirm your tag details.
7. Confirm your configuration settings and select Create to start provisioning the resource. Wait for the deployment to finish.
8. After the deployment finishes, select Go to resource to inspect your created resource. Here, you can manage your resource and find important information like the endpoint URL and API keys.
Create chat and embedding model deployments
In this step, you create an Azure OpenAI embedding model deployment and a chat model deployment. Creating a deployment on your previously provisioned resource allows you to generate text embeddings (i.e. numerical representation for text) and have a natural language conversation with your data.
1. Select Go to Azure OpenAIStudio from the toolbar to open the studio.
2. Select Create new deployment to go to the deployments tab.
3. Select + Create new deployment from the toolbar. A Deploy model window opens.
4. Add the following information to create a chat model deployment:
What
Value
Select a model
Select gpt-35-turbo.
Model version
Select 0301.
Deployment name
Add a name that's unique for this cloud instance. For example, chat-model because this model type is optimized for having conversations.
5. Select Create.
6. Select + Create new deployment from the toolbar. A Deploy model window opens.
7. Add the following information to create an embedding model deployment:
What
Value
Select a model
Select text-embedding-ada-002.
Model version
Select 2.
Deployment name
Add a name that's unique for this cloud instance. For example, embedding-model because this model type is optimized for creating embeddings.
8. Select Create.
Step 3: Create an Azure App Service and Deploy the RAG Chat Application
In this step, you'll:
Fork the sample Repository on GitHub.
Create an Azure App service resource with a deployment from GitHub.
Modify Azure App service Application settings in the Azure portal.
Configure the Workflow to deploy your application from GitHub.
Test the website before and After adding the data.
Fork the sample Repository on GitHub
In this step, you create a copy from the source code on your GitHub account to be able to edit it and use it later.
3. Select an owner for the fork then, select Create fork.
Create an Azure App service resource with a deployment from GitHub
In this step, you create an Azure App service resource and connect it with your GitHub account to deploy a Python application.
1. Type app service in the search bar at the top of the portal page and select App Services from the available options.
2. Select Create Web App from the toolbar to start provisioning a new web application.
3. Add the following information to fill in the basic configuration of the application:
What
Value
Subscription
Use the same subscription you used to apply for Azure OpenAI access.
Resource group
Use the same resource group you created before.
Name
Enter a unique name for your website. For example, rag-mongodb-demo.
Publish?
Select Code. This option specifies whether your deployment consists of code or a container.
Runtime stack
Select Python 3.10.
Operating System
Select Linux.
Region
Select UK South. This is the region where the rest of the resources you created reside.
4. Add the following information to create the app service plan. You can scale it up later:
What
Value
Linux Plan
Select a pre-existing plan or create a new plan.
Pricing Plan
Select Basic B1.
5. Select Deployment from the toolbar to move to the deployment configuration tab.
6. Add the following information to enable continuous deployment from GitHub:
What
Value
Continuous deployment
Select Enable.
GitHub account
Select your GitHub account.
Organization
Select your organization. If you are using your personal account then select it.
Repository
Select rag-semantic-kernel-mongodb-vcore.
Branch
Select main.
7. Select Review + create.
8. Confirm your configuration settings and select Create to start provisioning the resource. Wait for the deployment to finish.
9. After the deployment finishes, select Go to resource to inspect your created resource. Here, you can manage your resource and find important information like the application settings and logs.
Modify Azure App service Application settings in the Azure portal
In this step, you configure the Application settings to make the website able to communicate with other cloud resources.
1. In the Web App resource, select Configuration from the left side menu.
2. Select + New applicationsetting to add new environment variables to the function configuration.
3. Add the following names and values one by one and select Ok. Make sure to add your own values.
These application settings are for the Azure OpenAI resources that you created:
You can get the Cosmo DB connection string from the Azure Cosmos DB for MongoDB vCore resource page.
Select Connection strings and copy the connection string. Make sure to replace the user and password with the ones you created.
These application settings are new and will be created when the application starts:
AZCOSMOS_DATABASE_NAME
<cosmosDatabaseName>
AZCOSMOS_CONTAINER_NAME
<cosmosContainerName>
Any value should work for them.
4. Select Save.
5. Select General settings to edit the application startup command.
6. Type entrypoint.sh in the startup command field and select Save.
Configure the Workflow to deploy your application from GitHub
In this step, you modify the GitHub deployment workflow to point to the folder that contains the application.
1. Visit your forked repository on GitHub and notice the failing workflow.
2. Open the function workflow file .github/workflows/main_ragmongodbdemo.yml.
3. Open the file and select the pen icon to edit it.
4. Modify lines 31 and 36 to the following:
31
run: cd src && pip install -r ./requirements.txt
36
run: cd src && zip ../release.zip ./* -r
5. Select Commit changes, and review your commit message and description. Select Commit changes.
6. Select Actions to review the workflow run status.
Test the website before and After adding the data
In this step, you test the application before adding the data, add the data, and test again.
1. Select the workflow name to open it and get the website URL.
2. Type in the chat message What is Azure Functions? and it should respond with I don't know.
3. Navigate to your Azure App service resource page and select SSH.
4. Select Go to open a new SSH page.
5. In the SSH terminal, run this command:
python ./scripts/add_data.py
6. Navigate back to the live website and type in the chat message What is Azure Functions? and it should respond with the correct answer now.
Congratulations!! You successfully built the full application.
If you want to learn how to add your own data see this guide on the repository's main readme.
Clean Up
Once you finish experimenting on Microsoft Azure you might want to delete the resources to not consume any more money from your subscription.
You can delete the resource group and it will delete everything inside it or delete the resources one by one that's totally up to you.
Conclusion
Congratulations! You've learned how to create an Azure Cosmos DB for MongoDB vCore cluster, how to create an Azure OpenAI resource, how to deploy an embedding model and a chat model from Azure OpenAI studio, how to create an Azure App service and configure continuous deployment with GitHub, and how to modify application settings to enable the communication across Azure resources. By using these technologies, you can build a RAG chat application with the option to perform vector search too over your own data and provide grounded (relevant) responses.
For MVP Diego Domingos da Silva, the journey to becoming a Microsoft MVP was never about collecting credentials. It was about showing up, learning in public, and finding people who made the tech world feel more human. A newer MVP in the program, Diego has built his reputation by helping others make sense of Microsoft 365 with honesty, humor, and heart. Along the way, the community became more than a professional network. It became a place of growth, connection, and support—and ultimately helped shape both his career and his life.
The spark that started it all
Diego’s path into the community started with a challenge from a manager: build a personal brand. At the time, he was working in Washington, D.C. and began experimenting with a blog that would eventually grow into his recognizable voice in the Microsoft 365 space. He attended his first Microsoft 365 Community Conference in Las Vegas shortly after the pandemic, where one session about making community part of your career shifted his perspective. Instead of watching from the back, he moved to the front of the room - curious, observant, and determined to understand how people built careers through sharing what they knew.
“I had zero of the knowledge, but I had the curiosity. I went to the front of the room because I wanted to see how it was done.”
That curiosity turned into action. After encouragement from community leaders, Diego submitted sessions, spoke at events, and kept returning - not because he was chasing a title, but because he loved the energy of helping others and learning alongside them. He discovered that community work is not only what happens on stage. It is also the invisible work: moving chairs, carrying pizza boxes, welcoming newcomers, and creating spaces where people feel they belong. Over time, mentors encouraged him to keep going, build meaningful contributions, and trust that impact matters more than perfection.
MVP Diego Domingos da Silva delivering a session, “SharePoint at 25: Lessons from the Scars” at M365 Philly
Behind the scenes, Diego was also navigating profound personal loss. In that season, the M365 community became far more than a place to talk about technology. It gave him a sense of safety, connection, and stability when he needed it most. That experience shaped the way he shows up today: candid, welcoming, and committed to making space for other people’s stories as well as their technical growth.
“Community wasn’t just my escape. Community was my lifeline. It was my safe space.”
MVP Diego Domingos da Silva and the Microsoft sign in Redmond, Washington at MVP Summit
What impact really looks like
One of Diego’s biggest lessons is that community impact is rarely about knowing everything. It is about listening well, staying humble, and helping people connect to the knowledge they need. That mindset has shaped how he contributes today as a Microsoft MVP in the M365 category, with a focus on SharePoint and M365 Copilot. On his Microsoft MVP profile, Diego describes his work as “flipping the script in M365 with SharePoint, Copilot, and the power of community,” a phrase that reflects both his technical focus and his people-first approach.
He also believes belonging grows when people bring their full selves into the room. That is part of what motivates his work to foster visibility and connection for underrepresented groups in tech spaces. Whether he is mentoring, speaking, blogging, or simply starting conversations that help people feel less intimidated, Diego keeps coming back to the same idea: meaningful community is built one generous interaction at a time.
“I do not know everything, but I know everyone who knows something—and I can help you get the information you need.”
Alongside his work in mentorship and storytelling, Diego is also actively creating new spaces for connection. Inspired by an LGBTQIA+ meetup at the Microsoft 365 Community Conference - organized with very little notice but still drawing a meaningful group - he recognized a deeper need within the ecosystem.
That moment sparked the creation of Pride in M365, a community for LGBTQIA+ individuals and allies across Microsoft 365, Power Platform, AI, and the broader Microsoft ecosystem. The group focuses on building connection, visibility, mentorship, and support through shared experiences and community conversations - with a clear message that everyone is welcome.
For Diego, the goal is simple but powerful: carry the energy of those in-person moments forward so that connection doesn’t start from scratch at every event. By creating a consistent space between conferences, Pride in M365 helps people show up already knowing they belong - and already recognizing a few familiar faces.
“If we can keep those conversations going between events, then by the time we show up at the next conference, we already know each other. That’s the goal - to make the community easier to find, easier to join, and a little more welcoming for everyone.”
MVP Diego Domingos da Silva at the LGBTQIA+ meetup at the Microsoft 365 Community Conference.
Keep showing up
If you are thinking about becoming a Microsoft MVP, Diego’s advice is refreshingly practical: pick something you genuinely enjoy, stay curious, and keep showing up. Expertise grows over time, but authenticity, empathy, and consistency are what help build trust. To learn more about Diego’s work, visit his Microsoft MVP profile and LinkedIn page, and explore the Microsoft MVP Program to see how community contributions can open doors - not just professionally, but personally too. Connect with the Microsoft 365 & Power Platform Community and Microsoft 365 Community Hub.
To find an MVP and learn more about the MVP Program visit the MVP Communities website and follow our updates on LinkedIn or #mvpbuzz.
Join us for a future live session through the Microsoft Reactor where we walk through what the MVP program is about, what we look for, and how nominations work. These sessions are designed to help you connect the dots between the work you’re already doing and the impact the MVP Program recognizes - with time for questions, examples, and real conversations.
Log in
