Copilot computer use on IBM i: should it drive your 5250?

GitHub shipped computer use for Copilot on October 1, and its announcement describes a target market without naming it: “workflows in legacy and GUI-only software that do not provide an API, command-line interface, or MCP integration.” If you run IBM i, that is a description of your 5250 sessions. The question is not whether Copilot computer use can poke at a green screen. It is which of your green-screen jobs should ever reach a screen at all, and how to set up the ones that do so your security officer does not have a reason to say no.

Short answer: most of them should not, and GitHub’s own documentation agrees with that.

What Copilot computer use actually does

Computer use is a public preview feature in Copilot CLI and the GitHub Copilot app on macOS and Windows. Once you turn it on, with /computer on in the CLI or Settings > Computer Use in the app, Copilot can read what is on screen, click controls, type, press keys, scroll and drag. GitHub’s concept page says it reads “accessible application content and visual context through your operating system’s accessibility tree or screenshots when visual context is needed.”

A few constraints matter before anything else:

• Local sessions only. It does not run on Linux or in a cloud session. The machine running the emulator is the machine running the agent.
• Off by default, approved per app. The first time Copilot wants to control an application it asks. You can allow it for the session, Always allow it, or decline. Always allow is saved locally and shared between the CLI and the app on that computer. Removing it later “does not revoke access already granted in a running session.”
• Admins can kill it. Organization-managed settings disable computer use, and a developer’s local setting cannot override that.
• It costs credits. Copilot CLI is available on every plan: Free, Pro at $10 a month, Pro+ at $39, Max at $100, Business at $19 per user and Enterprise at $39 per user (GitHub’s plans page, checked October 5; the Copilot review breaks the plans down). Agent work in the CLI draws on AI credits at $0.01 each. GitHub has not said which plans get computer use specifically, only that you should “confirm that the feature is available for your account.”

The part IBM i shops should read twice is the tip near the top of the same page: “If an API, MCP server, terminal command, filesystem tool, or dedicated browser tool can complete the task directly, that tool typically provides more structured information and predictable results.” GitHub is selling a fallback, and saying so.

Will it read ACS? Nobody has tested it

GitHub publishes no compatibility list, and its demo is an expense report in Safari. Nobody, GitHub included, has published a run against IBM’s Access Client Solutions emulator. So here is what the documentation implies, labelled as inference.

ACS is a Java application, and its 5250 emulator comes from IBM’s Host On-Demand code. On Windows, Java apps only show up to accessibility tools through the Java Access Bridge, and Oracle’s own accessibility guide states that “by default, Java Access Bridge is not enabled.” Even with it enabled, the 5250 presentation space is a painted grid of characters, not a tree of labelled text fields. Expect Copilot to work mostly from screenshots.

That is less bad than it sounds. A 5250 screen is fixed-pitch text on a 24 by 80 or 27 by 132 grid, which is about as legible as screenshots get. The problem is not reading. It is timing and commitment, which is where green screens differ from the web forms these agents are tuned on.

5250 is block mode. Nothing reaches your program until an AID key: Enter, a function key, Page Down. Enter commits, and there is no undo. While the host is working, the emulator shows input inhibited and locks the keyboard, and keystrokes typed into that window are dropped or buffered depending on your type-ahead settings. GitHub’s limitations section warns that “changes in timing or window state can produce different results, cause computer use to repeat an action, or prevent it from continuing.” On a web form a repeated click usually means a duplicate validation error. On an order entry screen it can mean a second order.

If you want the background on ACS itself, the ACS review covers what the emulator does and where it stops.

Most green-screen work should never reach the screen

Before you point an agent at a 5250 session, ask what the screen is for. For a large share of daily IBM i work, the screen is a display over data the system will already give you as rows.

WRKACTJOB, WRKSYSSTS, WRKUSRPRF, DSPOBJD and most of the WRK commands an operator lives in have SQL service equivalents in QSYS2. “Which jobs have used the most CPU” is a query, not a screenshot:

SELECT JOB_NAME, AUTHORIZATION_NAME, JOB_STATUS,
       CPU_TIME
  FROM TABLE(QSYS2.ACTIVE_JOB_INFO()) X
 ORDER BY CPU_TIME DESC
 FETCH FIRST 10 ROWS ONLY;

An agent that can run that gets exact values, sorted, with no paging through WRKACTJOB and no chance of misreading a column. IBM ships the plumbing for this. Its open source ibmi-mcp-server gives agents “secure, SQL-based access to Db2 for i” and names VS Code Copilot as a supported client. It runs over Mapepire on the IBM i (port 8076 by default, installed with yum install mapepire-server), and you define what the agent may run as YAML SQL tools. The same repo ships an ibmi CLI if you would rather have a coding agent shell out to ibmi sql than run a server.

That is the correct tool for monitoring, triage, user and authority reports, object lookups, and anything else where the question has an answer in a table. It is also the safer one, because the YAML file is an allowlist you can review, and a screen is not.

Where the screen really is the only API

There are real cases where computer use earns its place on IBM i, and they share one trait: the business logic lives in the display program, not in the database.

Vendor ERP entry screens. In a lot of packaged IBM i applications, the validation, defaulting, pricing and cross-file updates happen in the RPG program behind the order entry or receiving screen. Writing to the files directly skips all of it. If there is no vendor API and no batch interface, the screen is the only way in that keeps the data consistent. Today shops cover this with screen-scraping tools or a person keying from a spreadsheet.

Old in-house programs nobody wants to touch. Same pattern, homegrown. The program works, the person who wrote it is gone, and the last RPG developer problem means nobody is going to add a service program wrapper this quarter.

Regression testing on a test LPAR. GitHub pitches end-to-end testing as a use case. Walking an agent through a known screen flow after a PTF or a program change, and having it report what each screen showed, is a reasonable job for a tool that can read screens and does not get bored. On a test partition, a wrong Enter costs nothing.

What does not belong on this list: anything in production that changes data until you have watched it run the same flow cleanly on a test system many times, and anything with customer or employee data on screen. GitHub’s docs are blunt that screen contents become context for the model: “Only use computer use with applications and tasks whose visible content you are comfortable providing as context to Copilot.”

How to set it up so security signs off

The agent does whatever the signed-on user profile is allowed to do. The audit journal records the profile and the device, not “an AI did this.” That makes the user profile your real control, ahead of anything in Copilot’s settings.

1. Give it its own profile. Never let the agent drive a session signed on as you, and never as a profile with special authorities. A starting point:

CRTUSRPRF USRPRF(CPAGENT)
          USRCLS(*USER)
          SPCAUT(*NONE)
          LMTCPB(*YES)
          INLMNU(APPLIB/ORDINQ)
          TEXT('Copilot computer use - inquiry only')
          /* Set PASSWORD and PWDEXPITV per your policy */

LMTCPB(*YES) blocks command entry except for the short list of commands IBM allows for limited users, such as SIGNOFF and DSPMSG, so the agent cannot wander from your menu to WRKOBJ or a CL prompt. ORDINQ stands in for a menu that offers only the options the task needs. Grant object authority to the programs behind those options and nothing else. Set a distinct workstation ID in the ACS session configuration as well, so the job log and audit entries show a device name that obviously belongs to the agent.

2. Approve per session. Pick Allow, not Always allow, for the emulator. GitHub’s own guidance is to avoid Always allow for apps that “contain sensitive information or support high-impact actions,” which is a fair description of a signed-on 5250 session. Know the stop key: Esc twice in the CLI.

3. Start read-only. GitHub’s documented example prompt is already the right shape for a first run: open the app, “summarize the status information shown in the main window. Do not change any values or submit any forms.” Run that against an inquiry screen and compare what Copilot reports with what is on the screen before you let it press Enter on anything.

4. Prove it on a test LPAR first. Repeat the exact flow you care about until it is boring. Watch for the input-inhibited cases: a slow response, a message line, a subfile that needs Page Down. Those are where it will misstep.

5. Tell your admins it exists. If you are on Copilot Business or Enterprise, computer use is a managed setting. The people who own your Copilot policy and the people who own your IBM i security may not talk often. They should talk about this. The IBM i AI security piece covers why AI tooling changes the threat model on the box, and the ACS workstation piece covers why the PC running the emulator is already the weakest point.

If you want help writing the prompts for the read-only and testing jobs, the IBM i AI Field Guide has IBM i-specific prompts for documenting programs, which tells you what a screen flow is supposed to do before you hand it to an agent.

Bottom line

Turn it on for testing, not for production, and not as your first tool. For every green-screen task, ask whether the screen is the only place the logic lives. If the answer is no, and for status, jobs, users, objects and most reporting it is no, use SQL services, ideally through IBM’s MCP server, and keep the agent off the emulator entirely. If the answer is yes, as it is for a lot of vendor ERP entry screens, Copilot computer use is a credible replacement for screen-scraping scripts, on a test LPAR, under a dedicated LMTCPB(*YES) profile, approved one session at a time.

Nobody has shown it working against ACS yet. The first shop that runs it on a test partition and reports what happens will know more than anyone writing about it today, and that is the right order to do this in.

Frequently Asked Questions

Can GitHub Copilot automate an IBM i 5250 green screen?

In principle, yes. Copilot computer use, in public preview since October 1, 2026, can click, type and press keys in desktop apps on macOS and Windows, and a 5250 emulator is a desktop app. Nobody has published a test against IBM’s ACS emulator yet, so treat it as unproven and start with read-only tasks on a test system.

Which Copilot plans include computer use?

GitHub says Copilot CLI is available on every plan, from Free at $0 to Enterprise at $39 per user a month, but it does not list which plans get computer use. Its troubleshooting advice is to confirm the feature is available for your account. Agent work in the CLI draws on your monthly AI credits, at $0.01 per credit.

Is it safe to let an AI agent use a 5250 session?

Only with a dedicated user profile that has no special authorities, LMTCPB(*YES) and an initial menu limited to the task. Every action runs with that profile’s authority and the audit journal cannot tell the agent from a person. Approve the emulator per session, never Always allow, and keep screens with customer data out of scope, since screenshots go to the model as context.

What should I use instead of computer use for IBM i?

For anything you would answer with WRKACTJOB, WRKSYSSTS or a query, use SQL services. IBM’s open source ibmi-mcp-server exposes Db2 for i to agents including VS Code Copilot, through Mapepire on port 8076. GitHub’s own documentation says a direct tool like an MCP server gives more structured information and more predictable results than driving a screen.