DEV Community: Anoosh Ohadi

Testing Desktop Apps with AI Without Blocking Your Main Computer

Anoosh Ohadi — Mon, 02 Nov 2026 13:05:50 +0000

A practical workflow for moving interactive tests to spare machines, checking prerequisites, and getting useful test reports back.

There were days when I could barely use my own computer because an AI agent was testing an application I was building.

It would launch the app, move the mouse, click through the interface, and type. I had to leave the controls alone. If I clicked somewhere else or brought another window forward, I could interrupt the test.

Meanwhile, I had other projects to work on.

Several coding sessions could make progress in parallel. But once they needed to interact with applications on my desktop, they were competing for the same workspace.

A successful build still left work to do

I develop desktop applications, including a screen recorder. After an agent changed an interface, I wanted it to open the application and check what it had made.

Was the control visible? Did the interaction work? Had a layout change broken something elsewhere?

Reading the source and completing a build could answer some questions. They could not tell me everything I wanted to know about the running application.

This depends on how the test is run. Some desktop checks can run without taking over a user’s input, and browser automation can also interfere with someone’s desktop. My problem was specifically the tests that needed control of the same interactive environment I was trying to use.

Two agents could interrupt each other

With one application, I could sometimes step away and let the agent finish.

With several projects, that became harder. One agent could be interacting with an application while another brought its own window forward. The first agent’s next click might then land in the wrong place.

Opening another terminal did not give the agent another desktop.

I was already dealing with the overhead of finding the right project and session. Now, even after finding the work I wanted to continue, I sometimes could not use the computer to do it.

At one point, this constrained my work for much of a day.

Move execution to another computer

I had spare machines available. I wanted to move a project’s code and sessions to another computer and let development and interactive testing continue there.

The application could open on that machine. Its agent could use that desktop. I could keep using mine.

I developed a transfer workflow around that requirement: the destination needed the project files, the context required to continue the task, and an environment that could actually run the application.

A friend later mentioned an unused laptop at home. I connected that machine as well, so some work could run there over the internet.

The important part was where the application actually ran. Viewing my main computer remotely would still leave its desktop occupied. Running the project on another machine gave the test its own place to work.

The Unity project exposed a missing dependency

One of the projects I moved was a game I was building with Unity.

The destination laptop did not have Unity and some of the other prerequisites available on my main computer. Transferring the project files had not made it ready to continue the work.

I asked the AI to help extend the workflow to handle that setup as well. In the Unity case I worked through, this included preparing the destination with the tools the project needed.

That does not mean I have automated installation of every development tool. An unfamiliar dependency may still need additional setup, with AI assistance or manually. Required access and software licensing also need to be handled for the destination machine.

The transfer needed to account for the environment as well as the files.

A preflight checklist for the destination

For someone trying a similar arrangement, I would start with one project and one spare machine.

Before assigning several tasks, establish that the destination can complete one small, useful check.

My checklist would be:

Code state: Identify the branch or revision, including any local changes that need to travel.
Toolchain: Record the editor, SDK, runtime, and versions the project requires.
Launch procedure: Explain how to build and open the application.
Task boundary: Say what the agent should test and what it is allowed to change.
Evidence: Specify where to return logs, screenshots, and a short account of what happened.

Access should be arranged for the destination rather than assumed to exist. A handoff can record where approved credentials are managed without copying secret values into its notes.

Here is an example of the first task I would give the destination. This is a suggested brief, not a transcript from an actual run:

Open the project and report missing prerequisites before changing anything. Once the environment is ready, build the application, launch it, and open its settings panel. Check that the new control appears and responds to a click. Return the code revision, build result, a screenshot, and any errors. If you cannot complete the interactive check, say where you stopped.

A report that says the build passed should not leave me assuming the agent also opened and tested the interface.

Keep parallel work separate

Moving a task to another computer addresses the input conflict. Other parts of the work can still collide.

Two agents might edit the same files, use the same test account, or write their results to the same location.

I would give parallel tasks a clear code state and separate output locations. Where appropriate, separate working copies or worktrees can help keep changes attributable to the task that made them.

Git’s worktree documentation explains how separate working trees work within a repository:
https://git-scm.com/docs/git-worktree

A linked worktree on one machine is not itself a transfer mechanism to a different computer.

I would also ask the test report to identify the machine and revision it tested. A screenshot becomes more useful when I can connect it to the build I asked the agent to check.

Match the machine to the test

An available laptop is a starting point. Whether it can do the work still needs to be checked.

Opening a settings panel is a different job from testing a demanding Unity scene or investigating recording behavior on particular hardware.

For Unity projects, the Hub documentation covers managing Editor installations, modules, projects, and licenses:
https://docs.unity.com/en-us/hub

I would establish the required environment before assuming the project is ready for unattended work.

Start with one task on one spare machine

I have not attached a timing study to this article, and I cannot give a measured percentage improvement.

The change I noticed was that I could continue working while an agent interacted with an application on another computer.

I could review another session, respond to a problem, or do my own work without worrying about interrupting the test with a click.

For a first attempt, I would pick a familiar project, identify its code state, prepare the destination, and ask for one small interactive check. Once the result can be traced back to the right machine and revision, there is a basis for adding more tasks.

I wrote about the broader experience in My Claude Code and Codex Workflow: The Problems I Had to Solve Myself.

When I began using AI to build more software, I expected the difficult questions to be about code. I spent considerably more time than I expected figuring out who got to use the mouse.

Author’s note: I am the founder of AigoPilot. The cover is an AI-generated illustration. The example task brief is a proposed workflow, not a transcript or benchmark.

Using CLAUDE.md and AGENTS.md in the Same Project

Anoosh Ohadi — Sun, 01 Nov 2026 08:04:41 +0000

Shared project rules for Claude Code and Codex, a small import when needed, and a separate record of unfinished work.

Cover: AI-generated illustration.

When I moved work from Codex to Claude Code, I sometimes spent the beginning of a session explaining things the project already knew. The previous conversation had the background. The new one had the code, but finding the same working assumptions took effort.

That experience helped shape the instruction-sharing workflow in AigoPilot, which I build and use. I am its founder. The underlying arrangement is also useful without the studio: keep durable project guidance in a shared file, make sure each tool loads it, and record unfinished work separately.

Check what your version already supports

Codex reads AGENTS.md for project instructions. Current Claude Code documentation describes direct support from v2.1.277, with version and configuration exceptions. Under its default selection, a project or local CLAUDE.md, .claude/CLAUDE.md, or CLAUDE.local.md in or above the working directory takes precedence over direct AGENTS.md loading.

That leaves two arrangements I would consider:

Shared file only: use AGENTS.md when both installed tools actually load it.
Shared file with a wrapper: keep AGENTS.md and a small CLAUDE.md importing it when that fits the environment or Claude-specific additions are needed.

Before adding a bridge, inspect the existing files and the instructions loaded by your session. Preserve useful rules already in the repository. There is no reason to replace a working setup just to match a diagram in an article.

Give the shared file a limited job

The first temptation is to put everything the project has ever discussed in AGENTS.md. That produces a document nobody can maintain confidently.

I would start with what a new contributor needs to avoid a predictable mistake: the project's purpose, where its important parts live, the relevant validation commands, and constraints that remain true across tasks.

Here is an illustrative starter. Replace the descriptions and commands with your repository's real ones before using it:

# Project instructions

## Purpose
This repository contains a desktop application and its supporting services.

## Working boundaries
- Preserve unrelated changes already present in the workspace.
- Read the existing implementation before proposing a replacement.
- Keep platform-specific behavior inside the existing platform layer.
- Explain a missing dependency or failed check instead of reporting success.

## Before making changes
- Identify the UI, platform integration, and test directories.
- Read the build and test configuration before choosing commands.
- State which files the task is likely to affect.

## Validation
- Run checks appropriate to the change.
- Report the commands run and their actual results.
- If a check cannot run, explain what is missing.

## Project-specific facts
Replace this section with the repository's verified paths,
build commands, and architectural constraints.

This is a proposed structure, not a description of my private repository. Its useful feature is that each instruction has a reason to be available across sessions. Temporary debugging notes belong elsewhere.

Add a thin Claude-specific wrapper when needed

For a setup that needs the import arrangement, the CLAUDE.md beside AGENTS.md can contain just this:

@AGENTS.md

This is Claude's documented import syntax. A prose reminder to open another file relies on the model deciding to do it. Put any necessary Claude-specific additions below the import.

Keep the dependency one way. Do not make AGENTS.md point back to CLAUDE.md. That makes the arrangement harder to reason about and can create an import loop.

I would choose this small text file over introducing a filesystem link into a Windows team's setup. If direct loading already gives you what you need, there may be no wrapper to add.

The import keeps one maintained source of rules. It does not make those rules free of context cost, or carry over a previous conversation's history.

Keep task state out of the permanent rules

A persistent instruction file answers questions such as which platform layer owns a feature. A handoff answers which change is unfinished today.

Mixing those two jobs makes old instructions look current. A note saying a test is failing can remain in a shared file long after the test has been repaired.

I prefer this separation as a starting design:

Durable repository expectations: AGENTS.md.
Necessary tool-specific additions: CLAUDE.md or supported tool configuration.
Current task, changed files, next action: a dated handoff note.
Long background explanation: a relevant document referenced from the instructions.

Use your own filenames for the handoff and background documents. The separation matters more than inventing another file convention.

Verify by asking a question, not by editing production code

Open a fresh session at the intended project location. I would begin with this read-only check:

Before making any changes, identify the instruction files that
apply to this working directory. Distinguish instructions loaded
at startup from files you opened during this check.

Summarize two project constraints and the validation commands
the repository actually defines. If no command is documented,
say so. Name any conflicting instructions you found.

Do not edit files or run build or test commands for this check.

This is a verification prompt, not a guarantee that a model's account of its own context is complete. Compare its answer with the files and the tool's inspection features.

In Claude Code, use /context to inspect memory files. Codex's instruction-discovery guide describes how its working directory and overriding files affect the result. For example, Codex recognizes AGENTS.override.md; Claude's direct AGENTS.md loader does not. Matching filenames do not mean identical discovery rules.

I would also check one nested part of the project where the rules differ. For example, UI work and a native integration layer may need different validation. Do not assume the two tools resolve every override convention identically.

For the first real task after switching tools, choose a small change that you can review easily. Check whether the session uses the right paths, preserves unrelated edits, and reports its actual validation. A convincing summary followed by work in the wrong directory is still a failed handoff.

The aim is a new session that can explain the project's working constraints before touching code. Its conversation history may be empty; the repository guidance should still be available.

I described the wider experience of managing projects, sessions and desktop tests in my Claude Code and Codex workflow. This shared-file arrangement addresses one small part of that experience: the project briefing I want available when another session begins.

References

Documentation checked November 1, 2026: