Research notes · 02

After Connecting ChatGPT to Codex on My Research Server

把 ChatGPT 和服务器上的 Codex 接起来以后

卞耀亮 / Yaoliang Bian (Jeff) · 2026 年 10 月 24 日 · 个人研究随笔

Read and discuss with AI

Copy the article and discussion prompt, then paste them into Claude or ChatGPT.

Open in Claude ↗Open in ChatGPT ↗

In my previous post, I described sometimes feeling like a prompt relay.[1] Codex worked on a server. I copied its progress into ChatGPT, discussed what to do, and carried the advice back. Before the project had moved very far, I had already made several trips between conversations.

I wanted to reduce more than copying and pasting. In a conversation with ChatGPT, I said, “I have noticed that much of my infrastructure work is meant to improve my efficiency.” It asked whether my bottleneck was waiting for experiments or personally analyzing the results and deciding what to do next. I answered, “Both.”

I wanted the tools to connect directly, and I also wanted work to continue after an experiment without always waiting for me to return. That was the aim. The interfaces built so far support only part of it.

That connection later became Research Hub, and I shared reusable parts on GitHub.[3] It was not a system designed in one sitting. Many choices had practical reasons: I needed an entry point that would stay online when I closed my Mac and put it in my bag.

Why go through Windows?

My Mac travels with me. When I leave my desk, I close it and put it in my bag, where it no longer stays connected. Hosting the connection on the Mac would make that entry point go offline with it.

Work on the research server does not necessarily finish when I close my laptop. I wanted to check progress and send advice through ChatGPT after leaving my desk, without first taking out the Mac and reconnecting it.

The Windows machine at my desk can remain powered on and connected. We therefore put the server connection and the ChatGPT entry point there. The Mac comes with me; Windows stays at the desk to maintain the connection.

This explains the two current routes. Codex on my Mac uses SSH to reach Windows, whose platform tools connect to the remote research container. ChatGPT uses an MCP tunnel to Windows to query filtered status or deliver advice into a fixed Codex conversation. The research code and experiments remain on the remote server.

While organizing the code, I asked whether this extra hop was redundant. It does add a machine to the route. But it serves a practical purpose in how I use my computers: the entry point does not depend on the laptop I carry around staying open and online.

Fewer trips to check progress and deliver advice

With an entry point remaining at my desk, the next question was what I repeatedly needed it to do. I often asked the server for progress, brought the reply to ChatGPT for discussion, and carried the resulting advice back.

The setup conversation proposed a small first milestone: when I asked ChatGPT for progress, it should retrieve real server status directly. Advice delivery, task submission, and recovery would follow in stages. Keeping the Windows collector running after the Mac disconnected was already part of that proposal.

Research Hub therefore provides status queries, advice delivery into a fixed conversation, and delivery receipts. ChatGPT can retrieve the status exposed by the interface and deliver advice directly, reducing the switching, copying, and pasting required for those operations.

The receipt tells me whether a message arrived. Delivery into a conversation does not mean Codex has begun processing it or that an experiment has started. This advisory interface does not automatically start a model turn; execution records are still needed to see what followed.

Some relay operations now have interfaces. I have not yet made a discussion in ChatGPT automatically lead to continued work on the server, nor measured the time saved. The concrete change is that checking status and delivering advice need not always involve my manually carrying the messages.

Using AI for research, and studying it too

In that conversation, ChatGPT also asked whether I wanted AI to help me become a more productive researcher or wanted to study how AI could conduct research autonomously. Again, I answered, “Both.” Both aims were present, but connecting tools and establishing research capability still require different kinds of work.

During setup I also asked, “What can I do while it is running?” ChatGPT suggested that Codex configure the connection while we continued reading papers. When it later described finishing the Hub before beginning experiments, I asked why we could not start the research task directly in Codex on the remote server. The discussion then separated the work: local Codex would build the connection while server-side Codex advanced the experiment.

This is another practical aim: configuration takes time, but work that can proceed independently need not wait for it. I could continue reading and discussing instead of watching a terminal for the next message to relay.

I have been attempting to reproduce RAX, a project in which AI writes robot-control programs through exploration.[2] We began with the click_mouse task and encountered sandbox and execution-environment problems.

During that work, I asked for progress, accepted an adjusted setup, and later explicitly requested a more complete reproduction of the original method. The requirements became more specific through conversation.

Adapting the setup can help work continue around an environment obstacle. Testing the original method requires returning to its specific conditions. Those stages serve different purposes, which need to be clear in the records; visible motion or output alone cannot distinguish them.

I also asked why some trials were not being performed autonomously by the RAX agent. A prearranged control procedure can help check simulation and control interfaces. An agent discovering a program through exploration is a separate result. Progress on the former does not establish completion of the latter.

I still participate in those judgments. Connecting the tools reduces some message handling, but it has not also delegated decisions about adapting the setup or interpreting the results.

Can it carry the work a little further?

That conversation also prompted me to pause. ChatGPT asked whether infrastructure was already taking more time than experiments, reading, and thinking. I replied, “It seems so.” Asked which project I would immediately pursue if all the infrastructure worked, I chose RAX. This was a reflection on how the work felt at the time, rather than a measurement of my time allocation.

The next problem is concrete too: once advice can be delivered, how can the agent act on it? After an attempt ends, how can it use the result to continue without waiting for me to prompt the next step?

First, I want to complete a RAX run under explicit conditions. The environment and execution prerequisites are not all working yet. These attempts cannot establish whether the original method succeeds, and the reproduction is not complete.

After that, I want to observe a practical change: given a task and a budget, can the agent inspect a result, choose the next step, and continue? When it needs me, can it identify the specific obstacle? That would make it easier to tell whether I have delegated more work.

Some connection code and deployment steps were reusable, and I wanted to exchange ideas with people facing similar needs. I organized them in AutoResearch Lab, which contains Research Hub code, tests, and deployment notes.[3]

More than adding another entry point, I want to see what happens during the next real task. With less relaying to do, will I need to supervise less, or will I simply supervise differently? I need more experience to answer that.

So far, I have delegated some message handling. Next, I want to delegate the step that follows a result: deciding how to keep the work moving.

Connect

If you use several AI tools together for research, I would like to hear which tasks you can already delegate comfortably and which still bring you back into the loop.

Personal website · Email

Reading and project

  1. Letting AI Run Research: Which Decisions Should I Delegate?
  2. Scaling Online Exploration for Robot Agents, Sections 10.1, 10.2 and 10.6
  3. AutoResearch Lab — Research Hub code and deployment notes
Based on actual usage conversations and experiment records, with AI assistance in drafting and revision. Existing interfaces, ongoing attempts, and future plans are distinguished. The RAX reproduction remains in progress.

把 ChatGPT 和服务器上的 Codex 接起来以后

我想少搬一点消息,也想看看,接下来能交出去多少工作。

用 AI 阅读与讨论

复制正文与讨论提示,再打开 Claude 或 ChatGPT 粘贴。

Open in Claude ↗Open in ChatGPT ↗

上一篇博客里,我说自己有时候像个 Prompt 中转站。[1] 服务器上的 Codex 在做事,我把它的进展复制给 ChatGPT,讨论一下,再把建议传回去。一轮下来,事情还没往前走多少,我先搬了好几趟消息。

但我想省掉的也不只是复制粘贴。在和 ChatGPT 的一次讨论里,我说:“我发现我很多的基建都是为了提高我的效率。”它问我,最浪费时间的是等待实验运行,还是实验结束以后需要自己分析、决定下一步。我回答:“都有。”

所以我一方面想让两边直接连起来,另一方面也希望,实验结束之后,不必每次都等我回来,工作才能往前走。这是我想做到的事情;现在搭出的接口,只完成了其中一部分。

这套连接后来被整理成了 Research Hub。我把其中可以复用的代码放到了 GitHub。[3] 它不是一开始就设计好的系统,很多安排都有很具体的原因,比如,我需要一个不会随着 Mac 合上、放进包里就离线的入口。

为什么要绕一趟 Windows

Mac 是我平时带着走的电脑。离开工位时,我会合上它,放进包里。这时它就不能继续保持联网。如果把连接入口放在 Mac 上,这个入口也会跟着我离开工位而断开。

但服务器上的工作,不一定恰好在我合上电脑的时候结束。我希望离开工位后,还能从 ChatGPT 查询进展、把讨论出的建议送过去,不必先把 Mac 拿出来重新连上。

工位上的 Windows 则可以一直开着、保持联网。所以我们把连接服务器的这一端放在 Windows 上,也把给 ChatGPT 用的入口放在那里。Mac 跟着我走,Windows 留在工位维持连接。

这也解释了现在的两条路径。在 Mac 上用 Codex 时,它通过 SSH 到 Windows,再由 Windows 上的平台工具连接远程研究容器。用 ChatGPT 时,则通过 MCP 隧道到 Windows,查询经过筛选的状态,或者把建议送进指定的 Codex 会话。代码和实验仍然在远程服务器上。

后来整理代码时,我也问过:这里是不是多绕了一层?单看机器之间的箭头,确实多经过了一台 Windows。但把我平时怎么用电脑考虑进去,就能理解这层中转的用途:连接入口不必依赖我随身带着的 Mac 一直开着。

查进展和传建议,也想少搬几趟

有了留在工位的入口,接下来要解决的是每次回来找它做什么。我最常重复的操作,是去服务器那边问现在怎么样,把回复拿给 ChatGPT 讨论,再把建议传回去。

回头看搭建时的对话,当时 ChatGPT 建议先做一个很小的目标:让我在这里问进展时,它能直接取得服务器上的真实状态。先把“看见进展”做出来,再逐步增加建议投递、任务下发和中断后的恢复。Windows 常驻、关闭 Mac 后仍能继续采集状态,也已经写在那时的方案里。

所以 Research Hub 先提供了这些接口:查询状态,把建议送进固定会话,留下投递回执。这样,ChatGPT 可以直接取得接口提供的状态,也可以直接投递建议,我不用为这几个动作反复切换、复制和粘贴。

回执是为了知道消息有没有送到。这里还得分清一步:送到会话,不代表 Codex 已经开始处理,更不代表实验已经启动。现在这条建议接口不会自动开启一轮执行。想知道后面发生了什么,还得继续查执行记录。

所以,我现在解决了一部分中转问题,还没有做到“在 ChatGPT 里讨论完,服务器就会自动接着做”。我也没有统计过到底节省了多少时间。眼下能确认的是,查状态和传建议不必每次都由我手动搬运。

我想用它做研究,也想研究它

在那次讨论里,ChatGPT 还问过:我是希望 AI 帮我做科研,让自己更高产,还是想研究如何让 AI 自主科研?我又回答了“都有”。这两个愿望确实都在。但把工具接起来,和证明它有了研究能力,中间还要做很多实际工作。

搭建 Hub 时,我还问过:“在他运行的时候我可以做什么”。ChatGPT 建议让 Codex 配置连接,我和它继续读论文。后来它又把顺序说成先搭完 Hub、再开始实验,我问,能不能直接在服务器上的 Codex 启动科研任务。随后讨论改成两边并行:本地 Codex 做连接,服务器上的 Codex 推进实验。

这也是我希望这套工具帮忙的地方:工程配置需要时间,但不用所有事情都等它完成。能够分开推进的工作,就让它们各自往前走。我也可以继续阅读和讨论,而不是守着一个终端,等着转发下一条消息。

最近我在尝试复现 RAX,一个让 AI 通过实际探索写出机器人控制程序的项目。[2] 我们先做其中的 click_mouse 任务,也遇到了沙箱和运行环境的问题。

这段过程里,我既要求它继续推进,也同意过为了适应环境调整方案。后来,我又明确提出,要按原方法做更完整的复现。这些要求是在对话中逐步说具体的。

比如,调整方案可以让我们绕开眼前的环境障碍,继续尝试;而要检验原方法,就得回到它的具体条件。这两个阶段各有目的,需要在记录里说清楚,不能只看最后有没有动作、有没有输出。

我也问过,为什么有些试验不是 RAX Agent 自己做的。提前安排好的控制步骤,可以用来检查模拟器和控制接口;但这和 Agent 自己探索出控制程序,需要分开看。前者有进展,不等于后者已经完成。

这些判断,我目前仍然在参与。连通工具以后,我可以少做一些消息搬运,但决定要不要调整方案、怎样理解眼前的结果,还没有因此一起交出去。

接下来,我想看它能不能多接着做一点

那次对话也让我停下来想了想。ChatGPT 问,花在基建上的时间是不是已经超过了实验、阅读和思考,我回答“貌似是”。当它接着问,如果这些设施都已经能用了,最想立刻推进什么,我说:“就还是RAX那个吧。”这不是已经做过的时间统计,却是我当时对自己工作状态的感受。

做到这里,我接下来想解决的问题也很具体:建议已经能送过去了,怎样让它在收到以后继续工作?一次尝试结束以后,又怎样让它根据结果接着做,而不用我再去催下一步?

我想先把 RAX 按明确的条件完整跑一遍。现在环境和执行条件还没有全部打通,不能用这些尝试判断原方法行不行,更不能说复现已经完成。

在这之后,我想观察一个很实际的变化:给定任务和可用预算,它能不能在一次尝试结束后,自己检查结果,决定下一步,再继续做;需要我回来时,能不能把卡住的具体问题讲清楚。到那时,才比较容易知道,我交出去的工作有没有增加。

这套连接里已经有一些代码和部署步骤可以复用,我也想和有相似需求的人交流,所以把它们整理到了 AutoResearch Lab。[3] 仓库里有 Research Hub 的代码、测试和部署说明。

相比再增加几个入口,我现在更想看下一次实际使用:少了中转以后,我会不会真的少操一些心,还是只是换了一种方式盯着它。这个答案,我还想继续做下去再看。

目前,我交出去了一部分消息搬运。接下来想交出去的,是拿到结果以后,继续往前做的那一步。

交流

如果你也在用多个 AI 工具一起做研究,欢迎交流:哪些工作已经可以放心交出去,哪些地方还总需要你回来接一下?

个人主页 · Email

相关阅读与项目

  1. 让 AI 自主推进科研:我在尝试委托哪些判断?
  2. RAX 原论文,第 10.1、10.2 与 10.6 节
  3. AutoResearch Lab — Research Hub 代码与部署说明