BUG: VSCode IDE Plugin on SSH Connection: "Failed to load tasks."

Same issue here, with remote-ssh on Cursor

Same issue on VSCode Insiders for MacOS with Codex 0.5.0

Same issue on VSCode remote-ssh on Ubuntu Linux 22.04 LTS

same issue on cursor and vsocode for macos ubuntu

Also VSCode insiders Windows 11 running in WSL2

0.4.0 also can not running with ssh remote. and it also broke the connection with mac os app!

I have the same issue with it When I connect to a remote server it doesn't load the tasks and I will get this error:
Failed to load tasks.

No matter how much I click on rety It doesn't load the previous history or tasks.
Version: 0.4.0

Same issue on local remote WSL too

Same issue on WSL.

Same issue on VSCode Insiders for windows 11 pro

Same issue here with VSCode 1.103.2 for Windows, Codex 0.4.0 plugin and remote-ssh on Ubuntu Linux 24.04.3 LTS

Same issue here in dev container

Same issue on VSCode remote-ssh

Hmm, two things to check:

• Is there a seemingly valid ~/.codex/auth.json on the remote host (I assume there is, or chat conversations would not work?)
• Is there any sort of firewall or other network configuration that would prevent those requests from going through?

In the settings.json for VS Code, I believe you can set:

"chatgpt.logLevel": "trace",  // any of "trace" | "debug" | "info" | "warning" | "error"

and then see log messages from the Codex dropdown in the Output pane (cmd+j to open on macOS, at least).

Is there anything there that sheds light on the error?

@bolinfest - Yes there's a valid ~/.codex/auth.json on both my local macOS system and the remote dev server [Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-79-generic x86_64)] - codex cli works from both systems using the local auth.json created through the codex cli OAuth login workflow.

I added the suggested settings.json entry and then cmd+j and bring up the output log and see this scrolling constantly, I hadn't checked this before so it may have been throwing these error outputs before even modifying settings.json.

This is the output console while connected via ssh to the remote ubuntu server via ssh.

<img width="2308" height="1300" alt="Image" src="https://github.com/user-attachments/assets/020fcc0b-c67e-4281-9130-c2d80655496e" />

@ben-vargas Thanks: this is very useful! @gpeal hopefully this gives you something to work with?

If I hit the "Retry" button I see this added line to the thrown error output; this error output logs while connected to the remote SSH server regardless of settings.json addition of chatgpt.logLevel.

<img width="3024" height="1964" alt="Image" src="https://github.com/user-attachments/assets/2c26702b-06bd-455c-bdd1-ffa38599383c" />

Switched to pre-release Codex extension on vscode and it worked

@bytecod3r - I tested on 0.5.3 and not resolved for me personally. Is that the pre-release you're running?

<img width="3024" height="1964" alt="Image" src="https://github.com/user-attachments/assets/27634e8a-974f-41cf-ae88-31275e25a355" />

@ben-vargas just in case 0.5.3 is the fix: did you update the extension on the remote host, not just in the client?

And yes (at least for now), we're going with odd minor version number -> pre-release; even minor version number -> mainline release.

@bolinfest - Correct, that's with 0.5.3 pre-release installed both locally on macOS and remote host.

<img width="3024" height="1964" alt="Image" src="https://github.com/user-attachments/assets/b2a49e90-f1cd-4a20-bc27-19360b6f4364" />

how does one install the latest 0.5.3 version in Cursor? I only see 0.4.0 to install there https://open-vsx.org/extension/openai/chatgpt

@epicwhale unfortunately, Open VSX (which is what Cursor must use because it is not allowed to talk directly to the VS Code Marketplace) does not support pre-releases as the Marketplace does. Currently, we only publish "mainline" releases to Open VSX.

@ben-vargas just in case 0.5.3 is the fix: did you update the extension on the remote host, not just in the client?以防万一 0.5.3 是修复程序：您是否更新了远程主机上的扩展，而不仅仅是在客户端？ And yes (at least for now), we're going with odd minor version number -> pre-release; even minor version number -> mainline release.是的（至少目前），我们将使用奇数次要版本号 -> 预发布；偶数次要版本号 -> 主线发布。

I have updated to the pre-release version 0.5.3, but the issue still exists and has not been resolved. @bolinfest @bytecod3r

<img width="1193" height="484" alt="Image" src="https://github.com/user-attachments/assets/30d58222-611f-48b1-9053-accde876e6f1" />

@epicwhale - You can try installing VSCode and accessing the pre-release VSIX there by right clicking the listing and downloading appropriate version and then installing that in Cursor. Kind of similar to the "copy all VSCode extensions" that Cursor does when a VSCode user first installs Cursor - that might get around the valid limitation bolinfest mentioned about Open VSX.

@ben-vargas you aren't alone with issue on 0.5.3, seems it's still broken

<img width="1776" height="248" alt="Image" src="https://github.com/user-attachments/assets/1d6891fc-555b-4ae8-a8e1-579b91319813" />

Failed to load tasks is still an issue on 0.5.3 on ssh connection, both Cursor and VSC Insiders.
Running MacOS -> Ubuntu 24.04.

Could you try following the headless authentication docs here?

I was just able to use codex (local and cloud) ssh'd into a remote machine.

@gpeal - What parts specifically from that guide? What do you mean by "I was just able to use codex"?

My remote dev server is already authenticated, the codex cli runs fine there, and even the Codex extension works in terms of sending a message with Chat or Agent mode while connected to the ssh server - this bug/issue is specifically that the task history fails to load. No tasks are shown (for example those run in codex web (https://chatgpt.com/codex) when connected to remote ssh host.

For example, failure to load any cloud tasks in codex extension while ssh'd into remote machine in cursor or vscode:

<img width="2402" height="1594" alt="Image" src="https://github.com/user-attachments/assets/68b71d1c-8856-49ad-b05e-6e6129d392ad" />

@gpeal - Also, while connected to the ssh remote host in vscode, if you do cmd+j (toggle the panel), go to output, select Codex filter, do you not have the constant scrolling of errors being thrown as pictured in the images shared above?

@ben-vargas I do not, everything (including cloud) loaded just fine for me. Can you walk me through how you set up your vs code ssh workspace, how you installed the extension, and how you did the headless login?

@gpeal - Really nothing special.

I have my macOS system (Darwin 24.6.0 arm64 arm) and remote server I ssh to (Linux 6.8.0-78-generic x86_64 x86_64) which is Ubuntu 24.04.3 LTS. It's hosted at hetzner in Oregon.

Both systems already had the codex cli installed an authenticated, both systems codex cli works via terminal and I use that daily (ChatGPT Pro subscription).

When the Codex IDE extension was announced I installed in Cursor locally, and then connected via ssh and also installed it remotely. That's when I noticed the problem and created this issue. Then I switched to VSCode to see if it was a compatibility issue with Cursor - same problem. Then since VSCode has access to pre-release version on the VSCode Marketplace, I updated to that version. Every time I installed, or switched to pre-release, I did it on the local macOS system (i.e. not connected via ssh in VSCode) as well as while connected to the Ubuntu system via ssh, so matching version on local host and remote host.

I've never been prompted by the extension on either Cursor or VSCode to execute the OAuth flow, so I presume it's picking up ~/.codex/auth.json already created and refreshing tokens from the cli use.

Thinking this might be an issue with using an older provisioned OAuth token from before Codex VSIX was released, I've tried logging out of codex cli and making sure ~/.codex/auth.json is removed in both systems... and then re-logging in on macOS to re-create the file, then transferred it to the remote system by via scp and ensured 600 file permissions.

In the past I've simply ran the OAuth workflow on each system independently and copied the redirect localhost:1455 URL and used curl '<redirect_url>' on the remote system in an ssh session to complete the headless setup, but most recently I avoided that (as described above) to make sure that wasn't part of the cause.

@ben-vargas Good debugging! You're correct that both the CLI and extension use ~/.codex/auth.json.

Could you do another test:
On the ssh machine, run codex apply TASK_ID where TASK_ID is the id in the url of one of your web tasks? It's okay if it's a random task that will have merge conflicts. I'm mostly curious if it's able to get the patch at all.

@gpeal - Sure, I asked codex web to write a markdown file and then ran the codex apply, that worked fine...

code@code-hil-1 in feat-test on  feat-test is 📦 v0.1.5
› codex apply task_e_68ba17fa47408323a8f2ecaa2c083347
Successfully applied diff
code@code-hil-1 in feat-test on  feat-test + is 📦 v0.1.5 took 1s
› ll
total 188
drwxrwxr-x 7 code code   4096 Sep  4 16:54 .
drwxrwxr-x 5 code code   4096 Sep  4 16:40 ..
drwxrwxr-x 2 code code   4096 Sep  4 16:40 bin
drwxrwxr-x 2 code code   4096 Sep  4 16:40 docs
-rw-rw-r-- 1 code code   1087 Sep  4 16:40 .env.example
-rw-rw-r-- 1 code code     88 Sep  4 16:40 .git
drwxrwxr-x 3 code code   4096 Sep  4 16:40 .github
-rw-rw-r-- 1 code code    582 Sep  4 16:40 .gitignore
-rw-rw-r-- 1 code code   1687 Sep  4 16:54 INSTALL.md
-rw-rw-r-- 1 code code   1066 Sep  4 16:40 LICENSE
-rw-rw-r-- 1 code code    142 Sep  4 16:40 .mcp.json.example
-rw-rw-r-- 1 code code   2037 Sep  4 16:40 MODULE_SYSTEM.md
-rw-rw-r-- 1 code code   1612 Sep  4 16:40 package.json
-rw-rw-r-- 1 code code 104757 Sep  4 16:40 package-lock.json
-rw-rw-r-- 1 code code  11823 Sep  4 16:40 README.md
drwxrwxr-x 2 code code   4096 Sep  4 16:40 scripts
drwxrwxr-x 7 code code   4096 Sep  4 16:40 src
-rw-rw-r-- 1 code code   1211 Sep  4 16:40 tsconfig.json
-rw-rw-r-- 1 code code   2172 Sep  4 16:40 wrangler.toml.example
-rw-rw-r-- 1 code code   2017 Sep  4 16:40 wrangler.toml.upgrade
code@code-hil-1 in feat-test on  feat-test + is 📦 v0.1.5
›

<img width="4010" height="2930" alt="Image" src="https://github.com/user-attachments/assets/1da58b02-ccfe-4e82-bbc7-ce290b901133" />

<img width="1488" height="836" alt="Image" src="https://github.com/user-attachments/assets/a208b3d5-3456-4715-a4ec-d1905e4c5127" />same problem

@moxi000 is that a ssh workspace? Have you successfully used Coded Web before?

@moxi000 is that a ssh workspace? Have you successfully used Coded Web before?

@gpeal Yes and Yes，After testing, I found that when using the shadowsocks protocol to connect to the VPN, this issue can be reproduced 100% of the time. You can try again. Even when the codex CLI is available and the web page is accessible, it still shows the error “failed to load tasks”.

Although it shows an error with repeated unsuccessful retries, the main coding function is not affected. Only the task history feature doesn’t work.

Although it shows an error with repeated unsuccessful retries, the main coding function is not affected. Only the task history feature doesn’t work.

Task history isn't the only thing. It also doesn't show the list of environments under input box

im facing this issue? any quick fix ? its troubling a lot

same here, commenting to follow up
it happened while connecting to remote server using VPN, and connection probably failed, after reconnecting the task is deleted. Despite the code changes are persistent, the task is not shown in VS code nor in codex website

0.4.5 is also affected

not a fix but if you just burned a ton of tokens and suddenly lost your very long and valuable session (like I did yesterday), discovered you can find the session log within the ~/.codex/sessions directory and you can perhaps recover some of your loss by passing this file or parts of it to new session:

(organized by timestamp so look for your most recent session):
example path:

# export SESSION_LOG_PATH=
~/.codex/sessions/2025/09/08/rollout-2025-09-08T14-46-27-5bc8f9e0-3a86-4814-a516-d6fecfc06f4c.jsonl

give that to a new session or whatever part might have been valuable to recover
(eg. reasoning text)

cat $SESSION_LOG_PATH |  jq 'select(.type == "reasoning") | .summary[]?.text'

(eg. the things I said)

cat $SESSION_LOG_PATH | tail -n +308 | jq 'select(.role == "user")'

but really hoping a fix can be found soon, failing task history makes the ide plugin nearly unusable and tons of developers use ssh with vscode/cursor/this is not an edge or minor use-case

@osterbit - Yeah, I hope they're actively pursuing this. I don't think we've seen confirmation that they've replicated it internally (I sure hope so, and this just hasn't been updated). Even more concerning than not being able to access my history when I use the IDE extension, is the fact that there doesn't seem to be any error backoff or end to the attempts to hit the failing endpoint(s), the errors in the output just scroll and scroll for as long as the IDE extension is running.

This is super painful. I hope a fix comes soon.

I'm also observing this behavior when using the plugin on a remote machine via the Remote - Tunnels extension.

I switched to the latest pre-release version on vscode in WSL2 and was able to get the tasks to load correctly. Normally though I am using a vscode fork (Positron) that relies on OpenVSX so I imagine the Positron version of codex won't work until the release version on OpenVSX gets updated to a working version.

@sudarshan227 - Interesting, I just pulled the latest pre-release on VSCode as well and I do see the cloud/web tasks now, but I also still see the constant 403s scrolling in the extenstion output. Can you check if yours is doing the same in VSCode as per screenshot below?

If the pre-release does work, you can probably download the pre-release or locate the vsix file installed in VSCode in the file directory and install it manually into a fork like Cursor or Positron.

<img width="3024" height="1964" alt="Image" src="https://github.com/user-attachments/assets/7a1fd418-e021-4050-a3e3-b2f5d73ad07b" />

I can confirm that my VSCode is still showing the constant 403s like your setup.

0.4.6 seems to have solved the issue for me

0.4.6 also resolves issue for me in cursor 🎉 🎉

@osterbit @FabrizioForch - Yeah, kind of like 0.5.6 I shared above, but the errors still scroll/throw constantly on both versions in my testing on my system.

I'd also be curious if you click the little "history button" (rollback clock), that doesn't work on 0.4.6 or 0.5.6 for me, works for you?

It doesn't appear to be fixed everywhere in the extension, and it still is throwing constant errors (multiple per second) which can't be good for your systems or theirs.

<img width="3022" height="1882" alt="Image" src="https://github.com/user-attachments/assets/0b83136b-84c3-46f1-a7d6-711a34a03ac6" />

I believe this is fixed with the vs code pre-release 0.5.7. Could somebody confirm?

@gpeal - Unfortunately, 0.5.7 in VSCode still has the problem on my system.

<img width="3024" height="1964" alt="Image" src="https://github.com/user-attachments/assets/eeccc1b3-1e97-49f4-9bb9-66e2fe903e9e" />

0.4.6 works for me

@KangningShen - Yeah, 0.4.6 and 0.5.6 seems to show the tasks in the main extension panel, but if you hit the history button does it show the tasks? And if you open the output console do you still see scrolling errors?

@gpeal - I dug in a bit more with the assistance of chatgpt-5-high to help troubleshoot, it seems Cloudflare is coming into play... this could explain differing behavior on different networks and operating systems across users reporting the issue:

---

You’re right that this isn’t (purely) an account/plan issue. I fetched one of the failing endpoints from the remote box using your current access_token and chatgpt-account-id and captured the full 403. It’s a Cloudflare browser challenge page:

• Headers include cf-mitigated: challenge and cf-ray: …-PDX.
• Body is the “Just a moment…” HTML that requires JavaScript and cookies to proceed.

This explains the difference you see:

• Local macOS: the VS Code webview (Chromium) runs locally and can complete Cloudflare’s JS challenge, sets __cf_bm, and subsequent /wham calls work.
• Remote SSH: the extension host/CLI runs on the Linux server (headless). Requests to https://chatgpt.com/backend-api/wham/ can’t execute the challenge, so Cloudflare returns 403 repeatedly.

What we tested on the remote

• Tokens present and fresh in ~/.codex/auth.json (access_token, refresh_token, account_id).
• Plan parsed from id_token: "pro".
• Probing the same endpoints with required headers on the remote host returns 403 and the Cloudflare challenge page for:
• /wham/accounts/check
• /wham/tasks/list?limit=20&task_filter=current
• /wham/environments

Seems to be working again with latest updates

Thanks @henrynw. Could a few other folks confirm if this is working now?

I can still replicate scrolling output errors in the latest release and history shows failure to load. Again, as my post above mentions - I think this is related to Cloudflare sitting in front of the backend endpoints used by Codex CLI.

Others still seeing errors thrown constanlyt in output?

<img width="3894" height="2386" alt="Image" src="https://github.com/user-attachments/assets/d2821e1b-5cac-4af2-98fd-dc78850009e7" />

<img width="620" height="766" alt="Image" src="https://github.com/user-attachments/assets/3e980281-1184-47fb-b2f4-efdfee43ed63" />

I can still replicate scrolling output errors in the latest release and history shows failure to load. Again, as my post above mentions - I think this is related to Cloudflare sitting in front of the backend endpoints used by Codex CLI. Others still seeing errors thrown constanlyt in output? <img alt="Image" width="2000" height="2000" src="https://private-user-images.githubusercontent.com/20713656/489756212-d2821e1b-5cac-4af2-98fd-dc78850009e7.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTc5NzU4MTksIm5iZiI6MTc1Nzk3NTUxOSwicGF0aCI6Ii8yMDcxMzY1Ni80ODk3NTYyMTItZDI4MjFlMWItNWNhYy00YWYyLTk4ZmQtZGM3ODg1MDAwOWU3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA5MTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwOTE1VDIyMzE1OVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTAyYjNjMzFkZTU5OWI3OGU3ZWM1MmI0NmQxMzAxYTk4MGEyNmIyYzk1MjZiMDYzMjRiN2FlZTRmMTJjMDFlYmYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.3a1Ot1_GplsJ4JIF7f2nD6Al-qXzx-A2jR71sHNTD6k"> <img alt="Image" width="620" height="766" src="https://private-user-images.githubusercontent.com/20713656/489756378-3e980281-1184-47fb-b2f4-efdfee43ed63.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTc5NzU4MTksIm5iZiI6MTc1Nzk3NTUxOSwicGF0aCI6Ii8yMDcxMzY1Ni80ODk3NTYzNzgtM2U5ODAyODEtMTE4NC00N2ZiLWIyZjQtZWZkZmVlNDNlZDYzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA5MTUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwOTE1VDIyMzE1OVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTljMDQyNjYwM2RkNWQwOGI5NTkwMmRjNzliZDdmMDY1ZWFiY2RjMzJkNWIzYzk1ZjZiZGRkM2FhZDY2ZmVhOGEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.olnsakxR_OZbtyAzWhVh-6aZgoiEL1fOQTsWXPFRVyY">

We do, too. We're just trying to track down the right CF changes that don't cause worse problems.

The issue was reintroduced for me in 0.4.9

2025-09-16 09:15:30.469 [error] Error fetching /wham/tasks/list?limit=20&task_filter=current: 403 Forbidden (97fe92b36edb0e01-MXP)

<img width="381" height="450" alt="Image" src="https://github.com/user-attachments/assets/8f1034ad-35fe-419a-bf16-617dbd5995a1" />

We changed some gateway settings. Can you let me know if the issue still persists?

@pakrym-oai and @gpeal - You rock, thank you for the persistence and willingness to chase this with me!

I can confirm I am getting history to load both locally and on remote ssh extensions in the the following versions (without any output errors from the extension):

• [Cursor] Codex (local) 0.4.10 - Working.
• [Cursor] Codex (ssh) 0.4.10 - Working.
• [VSCode] Codex (local) 0.5.11 - Working
• [VSCode] Codex (ssh) 0.5.11 - Working

CF changes appear to have resolved - thanks again! 🥳

I am also confident that this issue has been resolved. (I hope that the next version will not have this issue again.)

It works now! Thank you

Thank you friends and apologies for inconvenience!

The current version is 0.5.15, and the use of codex in the remote ssh extension of vscode is still stuck on thingking. Has anyone encountered the same problem as me?

我已经实现了VScode远程链接服务器端的codex，首先需要再服务器端安装Clash verge，打开全局，然后在终端设置nano ~/.bashrc
export http_proxy=http://127.0.0.1:7897
export https_proxy=http://127.0.0.1:7897
export all_proxy=socks5://127.0.0.1:7897
source ~/.bashrc
就可以了，然后就可以在window打开vscode使用ssh连接远程服务器的codex，

我已经实现了VScode远程链接服务器端的codex，首先需要再服务器端安装Clash verge，打开全局，然后在终端设置nano ~/.bashrc export http_proxy=http://127.0.0.1:7897 export https_proxy=http://127.0.0.1:7897 export all_proxy=socks5://127.0.0.1:7897 source ~/.bashrc 就可以了，然后就可以在window打开vscode使用ssh连接远程服务器的codex，

请问 必须要在服务器端使用代理吗？本地端流量转发没办法给服务端？

然后就可以在window打开vscode使用ssh连接远程服务器的codex，

你好，Clash verge的安装有相关网址嘛？

We changed some gateway settings. Can you let me know if the issue still persists?

I want to know how you changed the gateway 'cause I'm still encountering this issue when I tried to use codex on a remote server that hasn't got internet connection and has to redirect messages through a SSH backward tunnel on port 1080 to my machine. It'll help me a lot. Many thanks.