ChatGPT Work pushed desktop agents toward the default

ChatGPT Work makes the chat tab feel like an increasingly narrow container.

Once an assistant can work across files, browser state, applications, and prior runs, it is no longer just answering beside the task. It is participating in the task. That is useful precisely because the context is close to where the work happens.

It is also where the permission problem becomes real.

A desktop agent needs a structured run, not only a transcript. I want to know the request, the visible context, the allowed resources, proposed actions, approvals, verification, and final evidence. A run object can be paused, inspected, resumed, or handed to another person. A transcript mostly records that something happened.

The scope should be legible:

{
  "files": ["src/content/blog"],
  "browser": ["http://localhost:4321"],
  "network": "ask-before-use",
  "credentials": "none",
  "expires": "end-of-run"
}

Desktop context is personal before it is productive. A project directory can sit beside private notes, old exports, credentials, and unrelated files. A browser session can contain several identities. “Use my desktop” is not a useful grant.

The runtime needs smaller permissions:

• read this directory
• edit these files
• use this origin
• run this command
• ask before network access
• never read secrets
• expire the grant when the run ends

The model should not be responsible for remembering those boundaries. The environment has to enforce them.

Approval is most useful at the point of consequence. Replacing a paragraph in a local draft is different from sending mail, deleting a file, publishing a page, or moving data across accounts. The approval should show the target, the side effect, the evidence behind the proposal, and the recovery path.

proposed action:
  replace 6 paragraphs in src/content/blog/example.mdx

after approval:
  write the file
  run pnpm markdown:check on the edited post

rollback:
  restore the previous content from the diff

“Continue?” is not enough context for a consequential action.

The verifier also needs a separate job. A command can exit successfully while checking the wrong file. A browser click can work in the wrong account. A clean patch can still remove the important argument. Deterministic checks can confirm scope, command status, and changed files. A semantic verifier can ask whether the request was actually satisfied.

That verifier should look for gaps, not help the generator rationalize its result.

At the end of a run, I want a receipt rather than a victory paragraph:

changed:
  src/content/blog/example.mdx

checked:
  pnpm markdown:check src/content/blog/example.mdx

not checked:
  full site build

needs review:
  factual claims about product scope

The receipt lets a user decide whether to trust the result without rereading the entire conversation. It also gives the next run something concrete to inherit.

Task completion alone is too thin a metric for desktop agents. I would watch approval reversals, denied tool attempts, stale-context failures, verifier disagreement, scope violations, successful resumes after interruption, and the edits users make immediately afterward.

The work is already spread across the desktop: files, browser tabs, terminal output, local servers, screenshots, and half-finished drafts. Keeping the agent trapped in a chat window forces the user to ferry context by hand.

Removing that friction is the easy part. Making the access bounded, the approvals meaningful, the verification independent, and the receipt readable is the product.