Copilot can now control desktop apps. Start with a draft, not a submission.

Some recurring office work still lives behind buttons: copying an expense into a browser form, updating a presentation, or moving information between desktop applications. GitHub’s October 1 announcement brings computer use to public preview in Copilot CLI and the GitHub Copilot app on macOS and Windows. Copilot can read app context and operate the interface, including software without an API or command-line interface.

For a small business, that opens a practical route to testing tasks that are awkward to integrate. The first test should separate preparing a result from committing it. Giving an assistant permission to control an application is not the same as approving the expense, message, or record it might submit inside that application.

What the preview actually does

GitHub says Copilot can read accessible app content and visual context, click controls, enter and edit text, press keys, scroll, drag, and navigate workflows across applications. Its announcement illustrates an expense-report workflow in Safari and suggests tasks such as summarizing browser notifications or updating a presentation. Those are examples of supported kinds of interaction, not published reliability measurements for your software.

The distinction matters when evaluating an old desktop tool. A graphical interface can make automation possible even when there is no integration endpoint, but the assistant still has to identify the right controls and preserve the meaning of the information it moves. A completed sequence of clicks does not establish that the final record is correct.

The announcement does not provide a task-success rate, a time-saving estimate, or a guarantee that every application works. It also does not announce Linux support. Treat this as a preview to evaluate on the stated platforms, not evidence that unattended office automation is ready across the business.

App approval comes before app control

Copilot asks for approval before controlling an app. GitHub also says users can review or reset applications they have chosen to always allow. That makes the permission decision worth revisiting after a trial; an app that was harmless in a test can contain sensitive or consequential work later.

On macOS, the feature guides users through Accessibility and Screen Recording permissions. Organization-managed settings can disable computer use. If an organization has disabled it, that is a policy boundary to resolve with its administrator, not a setup problem to work around.

In Copilot CLI, the documented commands are:

• /computer on to enable computer use.
• /computer show to check its status.
• /computer off to disable it.

In the Copilot app, open Settings, select Computer Use, and turn on Enable Computer Use. GitHub says /computer on is available there too. The computer-use documentation is the product reference for further setup details.

None of these statements means that Copilot must ask again before every click or business action. In particular, choosing to always allow an application should not be treated as a guarantee that sending a message or submitting an expense will require a second approval. Your workflow needs its own decision about who owns that final action.

Test a draft before a live submission

Start with one repeatable task using a sanitized example and a test account or document where possible. An expense workflow is a useful candidate only if you can keep the trial out of live payment and reimbursement processing. Ask the assistant to prepare the draft and stop before submission; have a person inspect and submit it manually.

That stopping instruction is a proposed pilot constraint, not a GitHub-enforced checkpoint disclosed in the announcement. Where the application permits it, use an account that cannot submit or approve live transactions. A prompt can communicate the boundary, but it should not be the only thing protecting a consequential action.

Before the trial, record the applications involved, the permitted edits, the fields that must match the original, and the action reserved for the reviewer. For an expense draft, that could include the amount, currency, date, category, and attached document. These are suggested checks, not a claim about GitHub’s expense demonstration or your accounting policy.

Then run the same kind of task more than once. Compare the prepared result with the source each time, and record corrections, unexpected navigation, and time spent reviewing. If a dialog changes or a required field is missing, stop and inspect the state instead of asking the assistant to improvise through it. Measure the review work alongside preparation time; a faster draft that needs more checking may not improve the process.

Choose the interface that fits the task

Computer use is especially relevant where the interface is the only available route. If the software already offers a supported integration, compare that option before choosing GUI automation. Structured fields and documented operations can make some tasks easier to validate, though they still need permissions, error handling, and review appropriate to the action.

Our earlier Copilot remote-control article covers a different question: the host and device policy around remote sessions. This preview is about Copilot operating desktop applications. Do not assume that remote-session controls describe the app approval behavior announced here.

A useful first outcome is modest: the assistant prepares an accurate draft, the reviewer understands what changed, and the team knows how to disable the feature and reset allowed apps. Keep live submission with a person until the pilot produces enough evidence to justify a different design. The announcement expands what Copilot can attempt; your trial establishes what it can do reliably in your workflow.

For help selecting that first task, explore process automation and integration or request a workflow review. Bring the workflow and a sanitized example, rather than access to a live business account.