# Codex Windows 后台进程怎么处理：哪些该保留，哪些可以结束

> 不要按进程数猜正常与否。先查任务、终端、Scheduled 运行或 Computer Use 是否仍在拥有工作，再按三条边界决定是否结束剩余进程树。

- URL: https://blog.laozhang.ai/zh/posts/codex-windows-background-processes
- Published: 2026-07-16
- Updated: 2026-07-16
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: 开发工具与智能体
- Tags: OpenAI Codex, Codex App, Windows, PowerShell, WSL2, 后台进程

---
Codex 窗口已经消失，任务管理器里却还挂着一组进程；或者再次启动只剩后台进程、没有可用窗口——这时先别按数量判断“正常不正常”。先确认当前任务、集成终端、Codex Scheduled 运行或 Computer Use 会话是否还在拥有这段工作。只要有明确所有者，就回到对应界面停止或完成它，不要直接结束整个进程树。

如果确认没有所有者，先保存提示词、补丁和终端输出，再从 Codex 正常退出，等 CPU 与磁盘活动稳定后复查窗口、父子进程关系和资源变化。只有三种情况值得考虑结束剩余进程树：它已经成为空闲残留；没有所有者却持续活动；或它阻止 Codex 重新打开可用窗口。之后只重新打开一次；同样症状再次出现，就停止反复强退，改为整理版本、环境、复现步骤和脱敏证据。

| 你现在看到的现象 | 先查谁在拥有工作 | 立即动作 | 怎样才算验证完成 |
| --- | --- | --- | --- |
| 任务或集成终端还在跑 | 当前任务、终端命令或待确认操作 | 保留进程，回到对应界面停止或完成 | 任务结束后活动自然回落，补丁和输出已保存 |
| Codex Scheduled 运行在后台执行 | Scheduled 运行记录与对应本地项目 | 从 Codex 的 Scheduled 界面管理，不把它当成 Windows 任务计划程序 | 运行状态结束，对应项目不再产生新活动 |
| 正常退出后进程树还在 | 先确认已无任务、终端、Scheduled 或 Computer Use 所有者 | 等活动稳定，复查父子关系与资源变化 | 空闲残留、无所有者持续活动或阻止重开三者之一成立时，才进入结束边界 |
| 再次启动只出现后台进程，没有窗口 | 旧进程树是否阻止新窗口建立 | 保存现场，正常退出；若仍无窗口且无所有者，再结束合格的残留树 | 只重新打开一次；窗口可用或已收集完复发证据 |
| 没有可见任务，CPU 或磁盘却持续活跃 | 再查终端、Scheduled、Computer Use 与正在写入的任务 | 做前后两次观察，不用单次刷新下结论 | 活动在无所有者状态下仍继续，或验证出它阻止重开 |
| node、cmd、PowerShell 或其他 shell 子进程看起来像孤儿 | 父子 PID、启动时间、当前任务与终端归属 | 先查关系和活动，不按进程名批量结束 | 能说明该树确实无所有者，且满足三条结束边界之一 |

## 先判断这组进程有没有“主人”

![Codex Windows 后台进程的正常所有工作、需检查状态与安全退出顺序](https://blog.laozhang.ai/posts/zh/codex-windows-background-processes/img/codex-windows-processes-cover.webp)

OpenAI 没有公布一个适用于所有 Windows 电脑的“Codex 正常进程数”。同一台电脑上，进程树也会随任务、集成终端、Git 操作、语言运行时、浏览器工具、Scheduled 运行、Computer Use、应用版本以及 Windows/WSL2 模式变化。所以，“进程多”只是一个需要继续问的现象，不是故障结论。

更稳的判断有三个维度：

1. **所有权：**哪个任务、终端、Scheduled 运行或 Computer Use 会话启动了它？
2. **活动度：**输出、文件、CPU 或磁盘活动还在合理前进，还是在没有工作时持续不退？
3. **退出后状态：**它是正在收尾，还是在明确退出后仍留下、阻止下一次正常启动？

一段程序在窗口关闭后短暂使用 CPU 或磁盘，可能只是保存文件、终止 shell、结束 Git 操作、写入索引或清理临时状态。任务管理器的一次刷新无法分辨收尾与无限残留。你需要的是停止所有工作前后的对照，而不是一个来自别人电脑的数字。

## 六种现象看起来很像，处理方式却不同

![Codex Windows 后台进程的六种症状、所有者检查与下一步](https://blog.laozhang.ai/posts/zh/codex-windows-background-processes/img/codex-process-symptom-router.webp)

不要跳过症状分流直接寻找“该杀哪个 exe”。Windows 里的 PowerShell、`pwsh`、`conhost`、Node、Git、Python 和 WSL 都是共用工具；它们可能属于 Codex，也可能属于 IDE、另一个终端、开发服务器或其他自动化。

### 任务或终端还在工作：保留，先从界面停止

如果 Codex 还在生成代码、运行测试、等待审批或持续输出终端内容，那些 helper 进程就有明确所有者。结束整棵树会中断命令，还可能让尚未保存的补丁、部分文件操作或外部服务调用失去上下文。

回到当前任务或终端，选择让它完成，或在该界面取消。之后要看到一个终态：已完成、已取消、已失败或已停止。只有 UI 上不再滚动，不能自动等同于终端命令已经结束。

### Codex Scheduled 运行：去 Scheduled 界面管理

截至 2026-07-16，OpenAI 的 [Scheduled 任务说明](https://developers.openai.com/codex/app/automations) 明确写到：面向本地项目的运行会在后台执行，同时要求电脑保持开机、桌面应用保持运行。因此，即使没有人正盯着前台任务，一棵 Codex 进程树也可能是有意后台工作。

打开 Codex 里的 **Scheduled**，核对运行名称、上次运行、下次运行，以及它使用本地 checkout 还是 worktree。如果不再需要，从 Scheduled 界面停止或禁用。只在任务管理器中杀掉进程，不会改变启动它的计划。这里说的 Codex Scheduled 也不是 Windows “任务计划程序”的同义词。

### 退出后还留着：先给收尾一个机会

关闭一个窗口与整个应用完成退出，不一定是同一个生命周期事件。如果你已经明确让 Codex 退出，也确认不再有任务、终端、Scheduled 或 Computer Use 工作，剩余树才进入“可能残留”范围。

这时仍不要用固定秒数做切割。先看父子数量是否收缩、资源活动是否稳定、文件写入是否结束。“还没有消失”不能单独证明泄漏；“无所有者且长期不收尾”才值得升级处理。

### 启动后只有后台进程：不要连续点应用图标

无窗口时反复启动，会让旧树、新树和你之后的恢复动作缠在一起。先记下已有树的启动时间，确认能否从任务、通知或终端中找回仍需保留的工作，然后只做一次干净恢复。

恢复后只打开一次 Codex。如果窗口出现，检查是否只回到一个连贯任务状态；如果仍然没有可用窗口，不要继续“强退—重开”循环。记下版本、环境、旧树启动时间和你实际点击的顺序，这比第三次重开更有价值。

### 没有任务却持续占用 CPU 或磁盘：先做前后对照

“空闲”不是看不见输出，而是你已经确认任务、终端命令、Scheduled 运行与 Computer Use 会话都不应继续工作。在任务管理器中先记一次 CPU、磁盘和内存状态，然后停止所有工作、正常退出，再看一次。

短暂峰值可能是索引、终端关闭、Git 工作或文件写入。要升级到结束进程树，需要满足“无所有者”与“活动仍持续”两个条件，或者它已经阻止可用窗口重开。不要把某个 issue 里的 CPU、内存或进程数折算成你的阈值。

### shell 子进程像孤儿：查父进程和启动时间

PowerShell、`pwsh`、`conhost.exe`、Node、Git、Python 或 WSL 并不因为出现在 Codex 附近就必然属于 Codex。任务管理器的树形显示、PID、父 PID 和启动时间，才能帮你将它们与当前任务或终端对上。

先停止你知道的所有者，观察哪一支随之结束。如果你正在 IDE 里跑 dev server，另一个 PowerShell 窗口也在跑测试，那么按名称杀掉所有 Node 或 PowerShell 很可能会伤及无关工作。目标是终止一支已验证无主的 Codex 树，不是清空开发机上所有 shell。

## 按八步顺序安全退出，解决后就停手

![Codex Windows 后台进程从保存工作到验证、有界结束与复发上报的八步顺序](https://blog.laozhang.ai/posts/zh/codex-windows-background-processes/img/codex-safe-exit-ladder.webp)

这条顺序的价值不在于“更温和”，而在于每一步都会缩小问题范围。哪一步恢复了窗口或让活动正常回落，就在那里停止，不要把后续破坏性动作当成例行清理。

1. **保存工作。**复制尚未发送的提示词，保存需要的终端输出，确认重要文件和补丁已落盘。如果任务仍在产生改动，明确选择让它完成还是从 Codex 取消。
2. **停止所有者。**取消活跃任务，停止你启动的终端命令，禁用不再需要的 Scheduled 运行，或结束当前 Computer Use 会话。
3. **正常退出。**只要界面还能响应，就使用应用的正常退出路径。不要从可响应的 UI 直接跳到强制结束。
4. **等活动稳定。**给终端子进程、文件写入和清理动作完成的时间。没有一个对所有项目、机器和版本都正确的等待秒数。
5. **做前后验证。**看窗口是否已经消失，进程树是否收缩或完全结束，CPU/磁盘活动是否停止，以及是否仍有已确认的所有者。
6. **只结束合格的残留树。**在没有所有工作后，剩余树必须是空闲残留、在无所有者时仍持续活动，或者阻止重新打开可用窗口，才可进入这一步。
7. **只重新打开一次。**确认是否回到一个可用窗口与一个连贯任务状态，避免制造多棵新树。
8. **复发就报告。**同样状态返回后，在重装、删状态或同时改多个设置前，保留版本、环境、时间和前后活动证据。

在任务管理器中，更安全的手工路线是找到顶层 Codex 所属组，再次确认没有仍在进行的工作，只在第 6 步使用 **结束任务**。如果 UI 无法结束一棵已验证的残留树，管理员可以使用 Windows 的树形结束选项：

```powershell
taskkill /PID <top-level-codex-pid> /T /F
```

`/T` 会包含子进程，`/F` 会强制终止。这正是它能恢复残留树、也能破坏正在进行工作的原因。不要粘贴猜测的 PID，不要用共用 shell 名称代替 PID，也不要在保存工作和追踪父子关系之前运行。

## 用任务管理器做一次前后对照

任务管理器最适合先回答三个问题：这组 Codex 进程是否还在变化？哪个子进程展示了 CPU、磁盘或内存活动？当所有任务、终端或 Scheduled 运行停止后，这些活动是否随之改变？

可以这样做：

1. 在 **进程** 视图展开 Codex 分组，同时看 CPU、内存和磁盘列。
2. 记录当时是否有任务、终端、Scheduled 或 Computer Use 正在工作，以及当前时间。
3. 从所有界面停止这段工作，正常退出 Codex，等活动开始稳定。
4. 再看同一组列，记下是完全退出、树形收缩，还是无所有者时仍持续活跃。
5. 需要 PID 和更清楚的父子对照时打开 **详细信息** 视图；需要查哪个文件仍在被读写时，再用资源监视器补充。

记录前后对照时，分开“活动变化”和“绝对数字”。内存使用没有立即归零不一定是故障；某一秒 CPU 上升也不一定是死循环。更能说明问题的是：无任务状态能否稳定重现，正常退出后树是否仍存在，以及该树是否与无窗口启动或持续活动同时出现。

## 用 PowerShell 还原父子关系，不靠名字猜

先用低隐私风险的快照，不要一上来就导出命令行。下面的 CIM 查询保留进程名、PID、父 PID 和创建时间：

```powershell
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match 'codex|powershell|pwsh|conhost|node|git|python|wsl' } |
  Sort-Object ParentProcessId, ProcessId |
  Select-Object Name, ProcessId, ParentProcessId, CreationDate
```

这个正则只是**观察辅助**，不是 Codex 进程的官方定义。它会把无关的开发工具一起选出，也可能漏掉名称不在列表里的辅助进程。正确用法是根据父 PID 和启动时间重建关系，再与 Codex 任务、终端和当时的操作时间对照，而不是将查询结果全部作为结束对象。

如果要保存一份轻量资源快照，可以运行：

```powershell
Get-Process |
  Where-Object { $_.ProcessName -match 'codex|powershell|pwsh|conhost|node|git|python|wsl' } |
  Sort-Object CPU -Descending |
  Select-Object ProcessName, Id,
    @{Name='CPUSeconds'; Expression={[math]::Round($_.CPU, 1)}},
    @{Name='MemoryMB'; Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}
```

这里的 `CPUSeconds` 是进程到当前为止的**累计 CPU 时间**，不是任务管理器里随时变化的即时 CPU 百分比。运行两次快照，观察累计值是否继续增加，再和任务管理器里的实时 CPU、磁盘列对照，才更容易判断活动是否仍在推进。`MemoryMB` 也只是工作集快照，不是“超过多少就异常”的阈值。

如果查询某个进程时遇到权限拒绝，把“无法读取”本身记进报告，不要只为了得到一张更漂亮的表就贸然提高权限。也不要默认公开 `CommandLine` 字段：命令行里可能包含仓库路径、分支名、提示词、文件名、访问令牌、客户信息或其他秘密。

## 把 Windows 原生 agent、WSL2 agent 与集成终端分开

截至 2026-07-16，OpenAI 当前的 [ChatGPT 桌面应用 Windows 文档](https://developers.openai.com/codex/app/windows) 将两种 agent 环境分开：一种在 Windows 原生环境中使用 PowerShell 与 Windows sandbox，另一种让 agent 在 WSL2 中运行。文档还把集成终端选项当成独立设置；选择哪种交互 shell，不自动等于 agent 就运行在哪个环境里。把 agent 环境切到 WSL 需要重启应用。

| 你正在使用的环境 | 可能看到的子进程 | 需要确认的事实 | 不要据此推断 |
| --- | --- | --- | --- |
| Windows 原生 agent | PowerShell、console host、Git、Node、Python 与项目工具 | 哪个 Codex 任务或终端启动了它们 | 看到 PowerShell 或 Node 就一定是残留 |
| WSL2 agent | Windows 侧 WSL host，加上 Linux shell 与项目工具 | 当前 agent 是否在 WSL2、使用哪个发行版与哪类项目路径 | 看到 WSL 就能证明 agent 卡死 |
| 集成终端选项 | 为交互终端选择的 shell | 这是不是你在 Codex 里主动打开并仍在运行的终端 | 终端 shell 选择等同于 agent 环境 |

不要把切换 Windows/WSL2 当成第一次恢复动作。切换会改变实验条件，并要求应用重启；如果你在记录失败前就同时换 agent 环境、终端、项目路径和权限，之后即使恢复，也很难知道真正改变了什么。更好的顺序是先保存当前失败状态和基线，只在问题可复现后一次改变一个变量。

如果进程树已经健康，真正的问题仍是桌面应用比 CLI 或 IDE 明显慢，请转到独立的 [Codex Windows 应用与 CLI 路径检查](https://blog.laozhang.ai/zh/posts/codex-app-slow-cli-vs-desktop)。那篇文章负责跨入口的同一提示基准；本文只负责后台进程的所有权、生命周期与安全恢复。

## Scheduled 与 Computer Use 都可能拥有后台工作

两类工作最容易被误判为“Codex 明明空闲却还在跑”：一类是 Scheduled 本地运行，另一类是 Computer Use 正在控制浏览器或其他 GUI。判断方法不是看前台有没有聊天文字，而是去拥有这段工作的界面确认当前状态。

### Scheduled：进程结束不代表计划已经关闭

Scheduled 本地运行需要电脑开机、桌面应用运行；它还可能使用本地 checkout 或隔离 worktree。你应该记录是哪一个计划、最近和下一次运行时间、项目位置类型，以及停止或禁用后是否还会产生新的本地活动。直接结束一次进程树最多中断这次运行，不会自动关闭未来计划。

### Computer Use：先结束会话，再观察相关活动是否停止

Computer Use 会故意让应用与浏览器工作持续一段时间。结束 Codex 树以前，先确认是不是仍有会话在运行；能够从所有界面结束时，就先在该界面结束，再验证浏览器和相关进程活动是否随之停止。

如果你的问题是如何启动、授权或监督 GUI 工作，而不是退出后为何仍有残留，请看 [Codex Computer Use 中文指南](https://blog.laozhang.ai/zh/posts/codex-computer-use)。这两个主题的交集只有一个：Computer Use 是可能的任务所有者，不是看到后台进程就能推定的故障原因。

## 复发时，交付一份能被别人复现的报告

![Codex Windows 后台进程问题的版本、环境、所有权、资源变化、复现步骤与隐私脱敏报告包](https://blog.laozhang.ai/posts/zh/codex-windows-background-processes/img/codex-windows-report-packet.webp)

一次强制结束也许能恢复窗口，但它没有解释为什么会复发。真正有用的报告会把应用版本、Windows 环境、当时有没有所有者、退出前后资源变化、复现步骤和恢复结果连在一起。这样，维护者才能区分一次性的任务收尾、Scheduled 或 Computer Use 所有权、某个环境组合的问题，以及可重复的生命周期故障。

OpenAI 当前的 [反馈与日志说明](https://learn.chatgpt.com/docs/reference/troubleshooting#feedback-and-logs) 将 Codex 问题引导到已有 GitHub issue 或新 issue，并提醒分享日志或会话记录前检查敏感信息。文档给出的会话记录位置是 `$CODEX_HOME/sessions`，但没有提供一条适用于所有 Windows 安装的通用应用日志路径。因此，不要从旧帖子中猜一个“官方日志目录”，也不要为了补齐报告而公开整个 session 目录。

在重装、删除状态或大范围改配置前，至少保存这些信息：

- Codex 应用版本、本地观察日期与时间
- Windows 版本、系统架构
- agent 环境：Windows 原生/PowerShell 还是 WSL2
- 与问题有关时，记录集成终端选择
- 项目类型，以及运行使用本地 checkout 还是 worktree
- **Tasks**、**Scheduled**、终端或 Computer Use 当时是否显示活动
- 可见症状：正常退出后残留、启动后无窗口，还是无所有者时持续高活动
- 顶层和子进程 PID、父 PID、启动时间
- 正常退出前后的 CPU、磁盘、内存观察
- 最小复现步骤，以及一次干净重开能否恢复

可以按下面的短模板提交：

```text
Codex 应用版本：
Windows 版本：
Agent 环境：Windows 原生 / WSL2
集成终端选择：
项目类型与路径类型：[必要时脱敏]
当时是否有所有者工作：任务 / Scheduled / 终端 / Computer Use / 无
可见症状：
最小复现步骤：
期望结果：
实际结果：
退出前后 CPU、磁盘、内存变化：
正常退出是否清除了进程树：
一次干净重开是否恢复：
```

公开前要删掉或替换提示词和 transcript 内容、token、客户数据、私有仓库名、用户名、完整本地路径与敏感命令行参数。PID 和版本可以帮助复现，但也要与具体时间、环境和行为绑定；它们只描述这一台机器的一次案例，不能升级为所有人的正常或异常标准。

## 这些“快捷修复”会让问题更难判断

### 按固定进程数判定异常

进程树随任务、工具、环境与应用版本变化。固定数量既可能误杀有所有者的工作，也可能放过数量少但无窗口、持续活动的残留树。用所有权、活动度和退出后状态替代数量阈值。

### 按名字结束所有 Node、PowerShell、Git、Python 或 WSL

这些工具在开发机上由多个程序共享。即使某个子进程确实由 Codex 启动，也应先确认父子关系，再结束顶层、已验证无主的 Codex 分支；不要让无关的 IDE、dev server 或终端一起退出。

### 一开始就删缓存、session 或 `.codex` 状态

这样可能同时丢失证据和配置，却无法回答“正常退出是否能清除这棵树”。先走可逆的所有者停止、正常退出与前后验证。只有在证据已经保存、官方支持或明确复现步骤要求时，才讨论更深的状态清理。

### 先重装，再考虑怎么复现

重装会改变应用文件、版本和部分本地状态。它可能暂时掩盖症状，也可能消掉最有价值的前后对照。一次恢复失败后先整理报告；不要把重装当成第一条诊断命令。

### 同时换 WSL 模式、终端、权限和项目位置

一次改变四个变量，即使恢复也不能告诉你是哪一个变量有效。保留基线，每次只改一项，并记录变化前后是否仍能复现。

### 反复强退、反复启动

一次有界恢复已经足够判断问题是否复发。继续循环只会制造更多树、更多时间线和更多丢失工作风险。第二次出现相同状态时，正确下一步是报告，不是再重复同一组破坏性动作。

## 常见问题

### Windows 上正常会有几个 Codex 进程？

没有官方公布的通用数量。活动任务、集成终端、Git 与语言工具、Scheduled、Computer Use、Windows/WSL2 模式和应用版本都会改变进程树。先判断谁在拥有工作、退出后是否收尾，以及无所有者时活动是否仍持续。

### 在任务管理器里结束 Codex 安全吗？

只有在你已经保存工作、停止任务所有者、尝试正常退出、等活动稳定并验证剩余树满足三条边界之一时，才是合理的恢复动作。这三条边界是：空闲残留；无所有者却持续活动；或阻止 Codex 重新打开可用窗口。更早强退可能中断终端、补丁、文件写入或外部工具。

### 为什么关掉 Codex 窗口后进程还在？

任务、集成终端、Codex Scheduled 运行或 Computer Use 会话可能仍在拥有后台工作，应用也可能正在做收尾。确认没有任何所有者并完成一次正常退出后，如果树仍不结束、持续活动或阻止重开，才按残留生命周期问题处理。

### 任务管理器里有 Codex，但窗口打不开怎么办？

不要连续点击应用图标。先记录已有树的启动时间，保存能够找回的工作，按八步顺序完成一次干净恢复，然后只重开一次。仍无可用窗口时，保存版本、环境、父子关系、资源变化和准确点击顺序，转入报告。

### CPU 或磁盘很高就能证明 Codex 卡住了吗？

不能。短暂活动可能来自 agent 任务、终端命令、Git、索引、Scheduled 运行或退出收尾。只有在你确认没有所有者、活动仍持续，并通过退出前后对照把它与剩余 Codex 树联系起来时，这个信号才足以推动有界结束或上报。

### `background_terminal_max_timeout` 能减少 Windows 后台进程吗？

不能。当前 [Codex 配置参考](https://learn.chatgpt.com/docs/config-file/config-reference#configtoml) 将它定义为后台终端输出的最长轮询窗口；它不是进程数量设置，也不是桌面应用残留树的一线修复项。只有在你诊断长时间后台终端轮询时，这个配置才可能与问题相关。

### 看到 node、cmd、PowerShell 或 WSL 子进程可以全部结束吗？

不可以按名字批量处理。先用父 PID、启动时间和当前任务还原归属，再停止所有者。只有顶层、已验证无主的 Codex 分支满足结束边界时，才结束那一支，并保留其他开发工作。

### 切换到 WSL2 会修好后台进程问题吗？

不应把它当成第一次恢复。Windows 原生 agent、WSL2 agent 与集成终端是不同维度，切换 agent 环境还要求重启应用。先保存失败基线，问题可复现后再一次只改变一个环境变量，才能知道切换是否真的有关。

### 报告时要上传哪个 Windows 日志目录？

当前官方说明给出了 `$CODEX_HOME/sessions` 作为会话记录位置，却没有给出一个适用于所有 Windows 安装的通用应用日志路径。优先提交版本、环境、所有权、父子 PID、前后资源变化与最小复现步骤；任何 session、日志或截图都要先脱敏，不要公开整个目录。

## 最后只记住一条处理规则

有任务、终端、Scheduled 运行或 Computer Use 会话拥有工作时，就保留 Codex 后台进程，并从拥有它的界面停止。没有所有者时，严格按“保存工作、停止所有者、正常退出、等活动稳定、前后验证、只结束合格残留树、只重开一次、复发就报告”的顺序处理。

这条规则既能解决眼前的无窗口、退出后残留或无主高活动，也能保留真正修复复发问题所需的证据。进程列表只是观察入口；所有权、活动度与生命周期才是结论。

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-07-16。

- [Scheduled 任务说明](https://developers.openai.com/codex/app/automations) (developers.openai.com)
- [ChatGPT 桌面应用 Windows 文档](https://developers.openai.com/codex/app/windows) (developers.openai.com)
- [反馈与日志说明](https://learn.chatgpt.com/docs/reference/troubleshooting) (learn.chatgpt.com)
- [Codex 配置参考](https://learn.chatgpt.com/docs/config-file/config-reference) (learn.chatgpt.com)