Connecting ChatGPT to a Local Dev Environment With Desktop Commander: My Remote MCP Experience

When using ChatGPT to assist with development in the past, I frequently ran into one problem:

ChatGPT can analyze code, suggest commands, and generate modification plans, but when it comes to actual execution, I still had to perform many operations myself in my local terminal.

A very common workflow was:

ChatGPT provides a command
↓
Copy the command
↓
Switch to the terminal to execute
↓
Copy the execution result
↓
Return to ChatGPT
↓
Continue analyzing the next step

ChatGPT provides a command
↓
Copy the command
↓
Switch to the terminal to execute
↓
Copy the execution result
↓
Return to ChatGPT
↓
Continue analyzing the next step

If it is just executing one or two commands, this is not an issue at all.

But when maintaining a long-term project, a single task might require continuously reading multiple files, checking Git status, running tests, analyzing results, and making further modifications. In such cases, this constant “copy-paste-switch” operation between ChatGPT and the local terminal quickly becomes a noticeable efficiency drain.

Recently, I started actually using Desktop Commander’s Remote MCP to connect ChatGPT to my own Ubuntu development environment.

After using it for a while, I found that:

What Desktop Commander truly improves is not just the efficiency of “executing commands,” but rather the reduction of a massive amount of unnecessary manual relay between ChatGPT and the local development environment.

Of course, its usage is not unlimited. Remote MCP itself has a Tool calls usage quota, and if your workflow also involves Codex, you need to pay extra attention to Codex’s own quota consumption.

This article records my actual process of installing, connecting, and using Desktop Commander.

1. What problem does Desktop Commander solve?

Through Remote MCP, Desktop Commander allows ChatGPT to access your own computer after authorization.

It enables ChatGPT to interact with real:

File systems
Git repositories
Project source code
Configuration files
Local terminal
Command execution results

File systems
Git repositories
Project source code
Configuration files
Local terminal
Command execution results

Previously, if I asked ChatGPT:

Why did this test fail?

Why did this test fail?

ChatGPT itself had no idea what the actual current state of my local project was.

I usually had to manually provide these things to it:

git status --short
git log -1 --oneline
git diff

git status --short
git log -1 --oneline
git diff

And then copy the test output, relevant code, and configuration files.

Sometimes a single issue required checking five or six files, and I had to keep pasting the contents of different files into the chat.

The significance of Desktop Commander is that it adds a bridge between ChatGPT and the local computer.

It changes the original flow:

ChatGPT
↓
Me
↓
Local computer

ChatGPT
↓
Me
↓
Local computer

Gradually into:

ChatGPT
↓
Desktop Commander
↓
Remote MCP
↓
Local computer

ChatGPT
↓
Desktop Commander
↓
Remote MCP
↓
Local computer

This way, much of the information that previously had to be relayed by me can now be fetched directly by ChatGPT.

2. Connecting your own computer via Remote MCP

Desktop Commander first requires registering the computer as a device accessible via Remote MCP.

After entering the device connection page, you will see a command similar to the following:

npx @wonderwhy-er/desktop-commander@latest remote

npx @wonderwhy-er/desktop-commander@latest remote

I am currently using Ubuntu, so I ran this command directly in my local terminal.

After running it, Desktop Commander guides the browser to complete device authorization.

There is a very important point here:

ChatGPT does not automatically gain local access permissions simply after the plugin is installed.

The computer must first go through explicit Remote MCP device authorization.

3. Verifying the device

Once Remote MCP starts, the browser enters the device verification page.

The page displays a device verification code and asks for confirmation:

Verify Device

Verify Device

After confirming, the page displays:

Device verified

This device is now authorized.

Device verified

This device is now authorized.

At this point, this computer officially becomes an authorized Remote MCP device.

4. Confirming the computer is Online

Returning to the Desktop Commander console, you can see the authorized devices.

My device shows as:

wangqiang-ThinkPad-T570

wangqiang-ThinkPad-T570

Status:

Online

Online

This page also has a design detail I care about:

You can click at any time:

Revoke

Revoke

to revoke a device’s authorization.

This means that Remote MCP does not leave you completely out of control after authorization.

If a computer is no longer in use in the future, you can actively disconnect it.

The page also shows the supported entry points for Desktop Commander, including ChatGPT, Claude, and other MCP clients.

So, more accurately, Desktop Commander provides a Remote MCP channel, and ChatGPT is one of the clients that can use this channel.

5. Installing Remote Desktop Commander in ChatGPT

After device connection is complete, you also need to install Remote Desktop Commander in ChatGPT.

The plugin page actually describes its functionality quite clearly:

Through Desktop Commander’s Remote MCP, ChatGPT can access the file system and terminal of an authorized computer.

After installation is complete, you can see:

Remote Desktop Commander plugin installed

Remote Desktop Commander plugin installed

And you can directly:

Try it in chat

Try it in chat

At this point, the complete link is basically established:

ChatGPT
   ↓
Remote Desktop Commander
   ↓
Remote MCP
   ↓
My Ubuntu
   ↓
Local files / Git repository / Terminal

ChatGPT
   ↓
Remote Desktop Commander
   ↓
Remote MCP
   ↓
My Ubuntu
   ↓
Local files / Git repository / Terminal

6. The real value is not “running a command for me”

When I first saw Remote MCP, I did not immediately feel it was particularly important.

Because purely in terms of functionality:

ChatGPT can run terminal commands for me.

This does not seem very complicated.

But after actually using it, I found that its most important value is not executing a specific command, but rather:

Letting ChatGPT directly acquire the development environment context.

The value of these two things is completely different.

For example, when troubleshooting an issue before, I might have needed to tell ChatGPT myself:

What the current Git HEAD is
Whether the working tree is clean
Which files were recently modified
Why a certain test failed
What the configuration file currently contains
What the process specified by the relevant documentation is

What the current Git HEAD is
Whether the working tree is clean
Which files were recently modified
Why a certain test failed
What the configuration file currently contains
What the process specified by the relevant documentation is

Now, after being authorized, ChatGPT can check many of these things on its own.

So the development model changes from:

I am responsible for gathering information
↓
I send the information to ChatGPT
↓
ChatGPT analyzes
↓
ChatGPT gives me commands
↓
I execute the commands
↓
I send the results back

I am responsible for gathering information
↓
I send the information to ChatGPT
↓
ChatGPT analyzes
↓
ChatGPT gives me commands
↓
I execute the commands
↓
I send the results back

Into:

I define task goals and boundaries
↓
ChatGPT acquires necessary context itself
↓
ChatGPT analyzes
↓
ChatGPT executes some operations
↓
Continues processing based on real results
↓
I am responsible for key decisions and final confirmation

I define task goals and boundaries
↓
ChatGPT acquires necessary context itself
↓
ChatGPT analyzes
↓
ChatGPT executes some operations
↓
Continues processing based on real results
↓
I am responsible for key decisions and final confirmation

This is where I feel the efficiency improvement is most obvious.

7. I currently mainly use it for go-tour-i18n

My typical actual use case right now is my own:

go-tour-i18n

go-tour-i18n

project.

This is the A Tour of Go multilingual translation project that I maintain long-term.

As the number of languages continues to increase, this project has long gone beyond simply “translating English into other languages.”

It has gradually formed a fairly complete engineering workflow:

Locale initialization
↓
Glossary
↓
TranslationUnit export
↓
Language generation
↓
Process
↓
Validation
↓
Candidate Snapshot
↓
Independent Quality Check
↓
Revision
↓
Promotion
↓
Course SEO
↓
Locale Surface Review
↓
Preview
↓
Production

Locale initialization
↓
Glossary
↓
TranslationUnit export
↓
Language generation
↓
Process
↓
Validation
↓
Candidate Snapshot
↓
Independent Quality Check
↓
Revision
↓
Promotion
↓
Course SEO
↓
Locale Surface Review
↓
Preview
↓
Production

Many of these stages also have strict:

Input files
Status checks
Git identity
validation
review gate
promotion gate
production gate

Input files
Status checks
Git identity
validation
review gate
promotion gate
production gate

Even if ChatGPT understood the entire process before, it still had a natural limitation:

It did not know exactly what state my local repository was in at that moment.

So I had to constantly tell it:

What the current HEAD is
What the git status is
What the just-executed CLI returned
Which batch is complete
Which file was modified
What the current diff is

What the current HEAD is
What the git status is
What the just-executed CLI returned
Which batch is complete
Which file was modified
What the current diff is

Now with Desktop Commander, much of this information can be read directly from the local environment.

For this kind of long-term project with many states and strict processes, the value is especially obvious.

8. My favorite types of tasks for it to handle

Based on actual usage so far, I believe Desktop Commander is best suited for development tasks that require continuously reading context and making sequential judgments.

For example, reading repository rules.

My project has many formal documents:

AGENTS.md
docs/...

AGENTS.md
docs/...

Previously, to prevent ChatGPT from using old rules, I had to constantly remind it:

Please refer to the current repository files and do not use old content from the chat.

Now it can read the current files directly.

Another suitable scenario is Git status checks.

During the development process, the following commands appear very frequently:

git status --short
git diff
git diff --cached
git log -1 --oneline

git status --short
git diff
git diff --cached
git log -1 --oneline

These operations themselves have almost no intellectual value, but previously I had to be responsible for executing and copying them.

There are also some issues that require checking simultaneously:

Source code
Tests
Configuration
manifest
glossary
Documentation

Source code
Tests
Configuration
manifest
glossary
Documentation

If I relied entirely on chat uploads and copying, the operations would be very tedious.

Remote MCP helps significantly with this kind of problem.

9. Desktop Commander also does not mean “letting AI do everything”

However, after starting to use Remote MCP, I actually became more certain of one thing:

Just because something can be automated does not mean all operations should be automated.

I now prefer to treat Desktop Commander as an advanced assistant that can truly enter the development environment, rather than handing over the entire computer completely to AI.

For example, Production releases, DNS/CDN modifications, destructive commands, important Git commits, live service changes, and visual acceptance that must be done manually, I still retain explicit manual control over.

Especially:

rm
Deployment
Release
DNS modifications
Live configuration modifications
Account operations
Payment operations

rm
Deployment
Release
DNS modifications
Live configuration modifications
Account operations
Payment operations

The risks of these types of operations are not on the same level as simply reading files.

So my preferred way to use it is:

AI handles reading, analysis, and mechanical operations
Humans handle boundaries, risks, and final decisions

AI handles reading, analysis, and mechanical operations
Humans handle boundaries, risks, and final decisions

Rather than pursuing “full automation.”

10. Desktop Commander itself also has usage quotas

This is something I only paid special attention to after I truly started using it frequently.

The lower left corner of the Desktop Commander console displays:

Tool calls

Tool calls

My status when taking the screenshot was:

12%

1,234 of 10,000 this month

12%

1,234 of 10,000 this month

Below that is also:

Upgrade to Pro

Upgrade to Pro

This means that, at least for the plan I am currently using, calls are not unlimited.

If you only occasionally ask ChatGPT to:

Look at a file
Check Git status once
Run a command

Look at a file
Check Git status once
Run a command

Then the call volume might grow relatively slowly.

But if you actually start using it for continuous development, a single “task” often involves more than one Tool call.

ChatGPT might need to:

List directory
↓
Read file
↓
Search code
↓
Read second file
↓
Run command
↓
Read command result
↓
Modify file
↓
Test again

List directory
↓
Read file
↓
Search code
↓
Read second file
↓
Run command
↓
Read command result
↓
Modify file
↓
Test again

So a seemingly uncomplicated task can actually generate multiple calls.

This made me realize:

Remote MCP itself is also a development resource that needs to be managed.

11. Desktop Commander’s Tool calls and Codex quota are not the same thing

There is also a very easily confused issue here.

I also use Codex simultaneously now.

In the relevant development interface, you can see:

Local
Linked Codex Web
Cloud

Local
Linked Codex Web
Cloud

And:

5 hours
1 week
Remaining usage

5 hours
1 week
Remaining usage

The quotas for Desktop Commander and Codex need to be understood separately.

On the Desktop Commander side, the most intuitive thing I can see right now is:

Remote MCP Tool calls

Remote MCP Tool calls

For example:

1,234 / 10,000 this month

1,234 / 10,000 this month

Whereas Codex has its own usage quota.

But there is another detail I only noticed after actual use:

Codex quota is not only potentially consumed when I actively enter Codex and manually send tasks.

While using ChatGPT to handle development tasks, I sometimes see ChatGPT pass certain tasks on to Codex for execution.

In other words, from my actual usage perspective:

I did not actively open Codex

I did not actively open Codex

Does not simply equate to:

This round definitely did not use Codex quota

This round definitely did not use Codex quota

Therefore, I now observe these resources separately:

ChatGPT's own usage
Desktop Commander Remote MCP Tool calls
Codex usage quota

ChatGPT's own usage
Desktop Commander Remote MCP Tool calls
Codex usage quota

A complete development task might involve more than one of these.

This also changed my subsequent division of labor among tools.

My goal is not to have all development tasks completed by Codex.

Instead, I prefer:

Can be safely completed by regular ChatGPT + Desktop Commander
↓
Use this combination as much as possible

Truly requires repository-level modifications, complex diagnostics, or heavier development tasks
↓
Then use Codex

Can be safely completed by regular ChatGPT + Desktop Commander
↓
Use this combination as much as possible

Truly requires repository-level modifications, complex diagnostics, or heavier development tasks
↓
Then use Codex

This allows different tools to each do what they are better suited for, while also making it easier to control quotas.

12. What it truly saves is “manual relay”

After using it for a few days, if I had to summarize Desktop Commander’s greatest value, I do not think it is:

AI can run the terminal now.

But rather:

A massive amount of manual relay has disappeared.

Previously, I spent a lot of time on:

Copying ChatGPT commands
↓
Switching to Terminal
↓
Executing
↓
Copying output
↓
Switching back to ChatGPT
↓
Pasting results
↓
Waiting for the next command

Copying ChatGPT commands
↓
Switching to Terminal
↓
Executing
↓
Copying output
↓
Switching back to ChatGPT
↓
Pasting results
↓
Waiting for the next command

The vast majority of these actions involve almost no real judgment.

But they continuously interrupt my train of thought.

When a task lasts half an hour or even several hours, the number of these switches is very significant.

Remote MCP does not replace the most important technical judgments.

It is more about reducing these:

Mechanical operations that humans really do not need to do personally, but previously had no choice but to do.

This is probably also why I felt a noticeable improvement in development efficiency after using it.

13. Why do I increasingly value this model now?

In the past year or two, AI programming tools have proliferated.

Many tools emphasize:

Generating code
Automatically modifying projects
Automatically completing tasks

Generating code
Automatically modifying projects
Automatically completing tasks

But I increasingly feel that what truly affects long-term development efficiency is not just whether the model can generate correct code.

There is also a very practical issue:

Whether the model can see the real working environment.

If every time AI starts a task it can only see a small snippet of content copied in by the user, then even if the model itself is very smart, it will incur massive context-passing costs.

And this Remote MCP model solves:

AI
↓
Directly interacting with the real development environment

AI
↓
Directly interacting with the real development environment

This makes ChatGPT no longer just “answering questions based on a small piece of material I provide.”

It begins to be able to actively acquire the information needed to complete tasks.

I think this change might be more practical than simply improving code generation capabilities a bit more.

14. Who might be best suited to use it?

If you usually only occasionally ask ChatGPT:

What does this code mean?

What does this code mean?

Or:

Write a function for me.

Write a function for me.

Then the improvement brought by Desktop Commander might not be so obvious.

But if you regularly maintain real projects, and your work involves a lot of:

• Git repository operations
• Multi-file analysis
• Test troubleshooting
• Log analysis
• Configuration checks
• CLI workflows
• Repetitive project maintenance

Then the value of Remote MCP will be much more obvious.

I myself clearly belong to the latter scenario.

Especially for increasingly engineering-heavy projects like go-tour-i18n, a lot of the work is not actually difficult, but there are many steps.

This type of project is particularly well-suited for reducing manual relay.

15. My current positioning of Desktop Commander

After this actual usage, I will not temporarily define Desktop Commander as:

An AI fully automated development tool.

I prefer to understand it as:

The missing bridge between ChatGPT and the real development environment.

ChatGPT itself can already:

Understand requirements
Analyze code
Design solutions
Generate modifications
Determine errors
Explain test results

Understand requirements
Analyze code
Design solutions
Generate modifications
Determine errors
Explain test results

And what Desktop Commander fills in is:

Real file system
Real Git repository
Real Terminal
Real project status
Real execution results

Real file system
Real Git repository
Real Terminal
Real project status
Real execution results

Once these two parts are connected, the development experience has indeed undergone a noticeable change.

16. Issues that still need continued observation

Although I have now confirmed that Desktop Commander helps my development work, it has not reached the point where “all future development work will depend on it.”

The two practical issues I am most concerned about right now are as follows.

The first is:

Are the monthly Tool calls enough for my actual development intensity?

I have now started using it for fairly long development workflows.

If the call volume continues to increase, whether I need an upgrade plan later will need to be judged based on actual usage data.

The second is:

Which tasks are most cost-effective to hand over to ChatGPT + Desktop Commander, and which tasks are still better suited for Codex?

I have now discovered that the two are not a simple replacement relationship.

Desktop Commander is better suited for helping ChatGPT acquire a real local environment, while Codex still has its own value in complex code modifications and heavier repository-level work.

I now prefer to form a stable division of labor, rather than stuffing all tasks into a single tool.

Summary

When I used ChatGPT for development in the past, it was more like a technical consultant sitting next to me:

I give it materials
↓
It analyzes
↓
It tells me how to do it
↓
I execute it myself

I give it materials
↓
It analyzes
↓
It tells me how to do it
↓
I execute it myself

After connecting Desktop Commander Remote MCP, it started to become more like a collaborator who actually enters the development environment:

I propose goals
↓
ChatGPT views the real repository
↓
Reads necessary files
↓
Runs some commands
↓
Continues analyzing based on real results
↓
I am responsible for key decisions and final confirmation

I propose goals
↓
ChatGPT views the real repository
↓
Reads necessary files
↓
Runs some commands
↓
Continues analyzing based on real results
↓
I am responsible for key decisions and final confirmation

I think this is the most valuable direction for this type of tool.

It is not about letting AI replace humans in making all decisions, but rather:

Handing mechanical operations that do not need to be done by humans over to tools, and leaving things that truly require judgment to humans.

At least from my actual experience in the go-tour-i18n project so far, Desktop Commander has indeed started to improve my development efficiency.

Next, I will continue to observe its Remote MCP Tool calls consumption, long-term stability, and how ChatGPT, Desktop Commander, and Codex can best divide their labor.

If there are significant changes in how I use it later, I will continue to document them.