{ "schemaVersion": 3, "generatedAt": "2026-08-13T18:03:28.303373Z", "date": "2026-08-13", "description": "Evidence-backed leads from open, unassigned issues.", "methodology": { "maintainerInvited": "Explicit invitation labels such as good first issue or help wanted.", "triageLead": "Unassigned documentation work or engaged bugs/enhancements without an explicit invitation.", "warning": "Re-check live GitHub state and ask maintainers before substantial work." }, "count": 100, "leads": [ { "tier": "maintainer-invited", "rankScore": 93, "reasons": [ "Maintainers marked this as a good first issue", "No assignee is listed" ], "caveat": "Confirm scope and availability with the maintainers before starting work.", "signal": { "id": "github:sgl-project/sglang:issue:13363", "source": "github", "group": "ai-infrastructure", "project": "sgl-project/sglang", "kind": "issue", "title": "[Roadmap] sglang auto tuner", "text": "Now we have many kernel backends for moe (e.g., triton, cutlass), attention, and allreduce. For each kernel, we can also tune some configs (e.g., the tile sizes in triton fused moe). Tuning these kernels and choosing dispatching heuristics can be non-trivial. We would like to build a simple command that auto-tune all the kernels and dispatch heuristic for a model. ## Todo 1. Implement a script sglang.auto_tune to tune the kernels and hyperparameters for a specific model. It should dump the optimal tile sizes/dispatching heuristics for all kernels used in this model. Example usage: - `python3 -m sglang.auto_tune --model-path Qwen/Qwen3-30B-A3B-Instruct-2507 --tp 8` - `python3 -m sglang.auto_tune --model-path Qwen/Qwen3-30B-A3B-Instruct-2507 --tp 4` 2. Start from tuning the triton fused moe https://github.com/sgl-project/sglang/tree/main/benchmark/kernels/fused_moe_triton 3. Implement a github action workflow that tunes 20 popular models on 5 common platforms. - The workflow should take in two arguments: a list of model names, and a list of runner names - Our CI has H100, H20, H200, B200, GB200 4. Auto choose allreduce algorithms (custom allreduce, nccl, nccl symmetric memory, torch symmetric memory). 5. Auto choose attention kernel backend and moe runner backend. 6. Auto tune the cutlass gemm kernels (with cutlass profiler) 7. Auto choose speculative decoding parameters for different batch sizes.", "url": "https://github.com/sgl-project/sglang/issues/13363", "createdAt": "2025-11-16T04:31:44Z", "updatedAt": "2026-08-13T07:20:24Z", "timestamp": "2026-08-13T07:20:24Z", "metrics": { "reactions": 29, "comments": 13 }, "labels": [ "good first issue" ], "author": "sglang-bot", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/sgl-project/sglang/issues/13363", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/sglang.html#signal-946cb508840b" }, { "tier": "maintainer-invited", "rankScore": 87, "reasons": [ "Maintainers marked this as a good first issue", "No assignee is listed" ], "caveat": "Confirm scope and availability with the maintainers before starting work.", "signal": { "id": "github:grafana/loki:issue:6994", "source": "github", "group": "observability", "project": "grafana/loki", "kind": "issue", "title": "grafana-loki lacks basic feature of extracting nested json labels", "text": " **Is your feature request related to a problem? Please describe.** I am running a java spring-boot application on AWS ECS and want to ship logs to loki/grafana. In order to have the java stack trace as a single log line in grafana I log as json to console using ```xml ``` The resulting json from AWS ECS looks like this: ```json { \"container_id\": \"ea7b47de37024af8a71629fc4c435e09-285964202\", \"container_name\": \"backend\", \"ecs_cluster\": \"dev-fargate\", \"ecs_task_arn\": \"arn:aws:ecs:eu-central-1:xxx:task/dev-fargate/ea7b47de37024af8a71629fc4c435e09\", \"ecs_task_definition\": \"dev-backend:72\", \"log\": { \"@timestamp\": \"2022-08-29T08:13:22.893Z\", \"@version\": \"1\", \"message\": \"Running with Spring Boot v2.7.3, Spring v5.3.22\", \"logger_name\": \"com.example.Application\", \"thread_name\": \"main\", \"level\": \"DEBUG\", \"level_value\": 10000 } } ``` **Describe the solution you'd like** I want to extract also lables from the log element, i.e. log level, logger name, ... and only keep the log.message as the log text. So therefore I need configuration like this (cloudformation yaml config), which is currently not working/supported: ```yaml ... LogConfiguration: LogDriver: awsfirelens Options: Name: grafana-loki Url: https://loki:3000/loki/api/v1/push Labels: \"{source=\\\"console\\\"}\" LabelKeys: container_id,ecs_task_arn,ecs_task_definition,ecs_cluster,container_name,log.level,log.logger_name,log.thread_name RemoveKeys: source,log.level_value,log.@version LineFormat: key_value insecure_skip_verify: true SecretOptions: - Name: TenantID ValueFrom: !Sub arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:parameter/config/loki/tenant-id - Name: log_router Image: grafana/fluent-bit-plugin-loki:2.6.1-amd64 Essential: false Memory: 512 Cpu: 256 FirelensConfiguration: Type: fluentbit Options: enable-ecs-log-metadata: true LogConfiguration: LogDriver: awslogs Options: awslogs-stream-prefix: firelens awslogs-group: !Ref LogGroup awslogs-region: !Ref AWS::Region ... ``` **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. I have also tried using LabelMapPath, but this didn't work either. Also tried LineFormat=json but has same result. **Additional context** This is really a basic feature I bet a lot of people need! And maybe another option would be great to specify the final message target, i.e. \"log.message\" in my case... and other properties should be ignored. Would extremly ease the config avoiding the need of specifying tons of \"RemoveKeys\"...", "url": "https://github.com/grafana/loki/issues/6994", "createdAt": "2022-08-29T08:42:40Z", "updatedAt": "2026-08-13T16:32:58Z", "timestamp": "2026-08-13T16:32:58Z", "metrics": { "reactions": 9, "comments": 12 }, "labels": [ "type/feature", "good first issue", "component/fluent-bit-plugin" ], "author": "sschmiedleitner", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/grafana/loki/issues/6994", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/loki.html#signal-72c1aca0b658" }, { "tier": "maintainer-invited", "rankScore": 82, "reasons": [ "Maintainers marked this as a good first issue", "No assignee is listed" ], "caveat": "Confirm scope and availability with the maintainers before starting work.", "signal": { "id": "github:sgl-project/sglang:issue:5979", "source": "github", "group": "ai-infrastructure", "project": "sgl-project/sglang", "kind": "issue", "title": "[Feature] Add KV cache usage prometheus metrics", "text": "### Motivation It would be great to track prometheus metrics for KV cache utilization. ### Related resources vLLM already offers KV cache utilization prometheus metrics, see [here](https://docs.vllm.ai/en/stable/serving/metrics.html), at `vllm:gpu_cache_usage_perc`.", "url": "https://github.com/sgl-project/sglang/issues/5979", "createdAt": "2025-05-02T14:59:34Z", "updatedAt": "2026-08-13T08:37:37Z", "timestamp": "2026-08-13T08:37:37Z", "metrics": { "reactions": 5, "comments": 11 }, "labels": [ "good first issue" ], "author": "jorgeantonio21", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/sgl-project/sglang/issues/5979", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/sglang.html#signal-e2ea6d644a15" }, { "tier": "maintainer-invited", "rankScore": 76, "reasons": [ "Maintainers marked this as a good first issue", "No assignee is listed" ], "caveat": "Confirm scope and availability with the maintainers before starting work.", "signal": { "id": "github:grafana/loki:issue:20673", "source": "github", "group": "observability", "project": "grafana/loki", "kind": "issue", "title": "Replace `go.uber.go/atomic` with Go standard library `sync/atomic`", "text": "## Summary We currently have a linter rule that blocks usage of `sync/atomic` and forces us to use `go.uber.go/atomic` instead. This rule was originally added because `sync/atomic` required atomic operations on primitive types, which was considered error-prone. However, since **Go 1.19**, the standard library `sync/atomic` package now includes typed wrappers (e.g., `atomic.Uint32`, `atomic.Int64`, `atomic.Bool`, etc.) that provide the same safety guarantees as `go.uber.go/atomic`. This makes the uber package redundant. ## Context Prometheus is also making this transition: - Issue: https://github.com/prometheus/prometheus/issues/14866 - PR: https://github.com/prometheus/prometheus/pull/18009 ## Proposed Changes 1. **Remove the linter rule** that blocks `sync/atomic` 2. **Migrate all `go.uber.go/atomic` usage** to the standard library `sync/atomic` typed wrappers 3. **Configure a linter rule** to block the old-style atomic functions that operate on primitive types (e.g., `atomic.AddInt64`, `atomic.LoadUint32`) to ensure we only use the new typed wrappers and avoid accidental misuse This approach gives us: - Fewer external dependencies - Alignment with the broader Go ecosystem - Same safety guarantees we had with uber/atomic ## References - Go 1.19 release notes on atomic types: https://tip.golang.org/doc/go1.19#atomic_types - `sync/atomic` package docs: https://pkg.go.dev/sync/atomic", "url": "https://github.com/grafana/loki/issues/20673", "createdAt": "2026-02-04T12:44:57Z", "updatedAt": "2026-08-13T16:32:33Z", "timestamp": "2026-08-13T16:32:33Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "good first issue" ], "author": "Segflow", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/grafana/loki/issues/20673", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/loki.html#signal-cb2618be817a" }, { "tier": "maintainer-invited", "rankScore": 67, "reasons": [ "Maintainers explicitly requested help", "No assignee is listed" ], "caveat": "Confirm scope and availability with the maintainers before starting work.", "signal": { "id": "github:vllm-project/vllm:issue:38175", "source": "github", "group": "ai-infrastructure", "project": "vllm-project/vllm", "kind": "issue", "title": "[RFC]: Support ViT Full CUDA Graph (Tracker)", "text": "### Motivation. Multimodal large language models (e.g., Qwen3-VL, Qwen3.5, GLM-V, Kimi K2.5) rely on a Vision Transformer (ViT) encoder to process visual inputs before feeding them into the language model backbone. In production serving scenarios, the ViT forward pass involves launching a large number of small CUDA kernels — including patch embedding, layer normalization, multi-head self-attention, and MLP projections — each of which incurs non-trivial kernel launch overhead on the host side. Currently, vLLM supports CUDA graph capture for the decoder (LLM) portion of the model, which has proven effective at reducing kernel launch costs and improving throughput. However, the ViT encoder is still executed eagerly, meaning every forward pass re-launches all kernels from scratch. Extending full CUDA graph support to the ViT encoder would allow the entire encoder forward pass to be captured and replayed as a single graph, eliminating per-kernel launch overhead and enabling more consistent, low-latency inference for multimodal models. ### Proposed Change. **Model Integration:** - [x] https://github.com/vllm-project/vllm/pull/35963 @b-mu - [x] https://github.com/vllm-project/vllm/pull/41736 @johncalesp - [x] https://github.com/vllm-project/vllm/pull/40830 @johncalesp - [x] https://github.com/vllm-project/vllm/pull/38061 @shen-shanshan - [x] https://github.com/vllm-project/vllm/pull/42151 @shen-shanshan - [x] https://github.com/vllm-project/vllm/pull/44720 @harsha20032020 - [x] https://github.com/vllm-project/vllm/pull/42224 @JisoLya - [x] https://github.com/vllm-project/vllm/pull/40576 @grYe99 - [x] https://github.com/vllm-project/vllm/pull/40660 @allgather - [x] https://github.com/vllm-project/vllm/pull/41759 @oguzhankir - [x] https://github.com/vllm-project/vllm/pull/41992 @oguzhankir - [x] https://github.com/vllm-project/vllm/pull/50929 @lk-chen - [ ] https://github.com/vllm-project/vllm/pull/42785 @YunzhuLu - [x] https://github.com/vllm-project/vllm/pull/43591 @JisoLya - [x] https://github.com/vllm-project/vllm/pull/46837 @anthonsu - [x] https://github.com/vllm-project/vllm/pull/43586 @shen-shanshan - [ ] https://github.com/vllm-project/vllm/pull/46005 @littlecircle0730 - [ ] https://github.com/vllm-project/vllm/pull/44394 @harsha20032020 - [x] https://github.com/vllm-project/vllm/pull/45254 @qyYue1389 - [ ] https://github.com/vllm-project/vllm/pull/51484 @gangula-karthik > [!NOTE] > **Integration Workflow:** > > 1. Implement ViT CUDA graph interface for the model referring to Qwen3-VL. > 2. Do tests: ut/e2e/benchmark/... > 3. Update supported model list in the [doc](https://docs.vllm.ai/en/latest/design/cuda_graphs_multimodal/#model-integration-via-supportsencodercudagraph). > 4. Add this model to CI test. **Bugfix / Improvement:** - [x] https://github.com/vllm-project/vllm/pull/38040 - [x] https://github.com/vllm-project/vllm/pull/38116 - [x] https://github.com/vllm-project/vllm/pull/40445 - [x] https://github.com/vllm-project/vllm/pull/40580 - [x] https://github.com/vllm-project/vllm/pull/41234 - [x] https://github.com/vllm-project/vllm/pull/41714 - [x] https://github.com/vllm-project/vllm/pull/42288 - [x] https://github.com/vllm-project/vllm/pull/42796 - [x] https://github.com/vllm-project/vllm/pull/43082 - [x] https://github.com/vllm-project/vllm/pull/43321 - [ ] https://github.com/vllm-project/vllm/pull/43403 - [x] https://github.com/vllm-project/vllm/pull/44484 - [x] https://github.com/vllm-project/vllm/pull/45654 - [ ] https://github.com/vllm-project/vllm/pull/45886 - [x] https://github.com/vllm-project/vllm/pull/46034 - [x] https://github.com/vllm-project/vllm/pull/49934 - [x] https://github.com/vllm-project/vllm/pull/51461 **Testing Coverage:** - [x] https://github.com/vllm-project/vllm/pull/40780 **Documentation:** - [x] https://github.com/vllm-project/vllm/pull/37914 - [x] https://github.com/vllm-project/vllm/pull/40355 - [x] https://github.com/vllm-project/vllm/pull/44388 ### Feedback Period. _No response_ ### CC List. @ywang96 @Isotr0py @wangshangsam ### Any Other Things. _No response_ ### Before submitting a new issue... - [x] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the [documentation page](https://docs.vllm.ai/en/latest/), which can answer lots of frequently asked questions.", "url": "https://github.com/vllm-project/vllm/issues/38175", "createdAt": "2026-03-26T02:22:01Z", "updatedAt": "2026-08-13T07:36:09Z", "timestamp": "2026-08-13T07:36:09Z", "metrics": { "reactions": 1, "comments": 27 }, "labels": [ "help wanted", "RFC", "multi-modality", "kimi" ], "author": "shen-shanshan", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/vllm-project/vllm/issues/38175", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm.html#signal-47643c5cdd83" }, { "tier": "triage-lead", "rankScore": 43, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:20214", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App frequently freezes/stutters on Windows 11 Pro despite sufficient system resources", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Latest Codex App downloaded from the Microsoft Store. ### What subscription do you have? Plus ### What platform is your computer? Windows 11 Pro, x64 CPU: AMD Ryzen 5 5600 RAM: 32 GB ### What issue are you seeing? I frequently experience Codex App freezes, stutters, or severe UI lag on Windows 11 Pro. This happens during normal usage, especially when: running prompts; opening existing/new chat sessions; switching into a conversation that has previous context. The app may become temporarily unresponsive or noticeably slow. This is not a full system freeze — the rest of Windows remains responsive. I checked Windows Task Manager while this happens, and system memory is not close to being fully used. My machine has 32 GB RAM and a Ryzen 5 5600 CPU, so this does not appear to be caused by insufficient hardware resources. Because this is a local desktop app running on a fairly capable machine, I would not expect frequent UI freezes during basic prompt execution or when opening chat records. This seems more likely to be a Codex App performance or optimization issue on Windows. ### What steps can reproduce the bug? Open the Codex App on Windows 11 Pro. Open an existing chat session, especially one with previous context. Run a prompt or continue the conversation. Alternatively, open a new chat record/session. The Codex App frequently becomes slow, freezes briefly, or shows heavy UI lag. This does not happen every single time, but it happens often enough to interrupt normal development work. ### What is the expected behavior? The Codex App should remain responsive while opening chats, running prompts, and switching between sessions. Even if a prompt is being processed or the context window is large, the UI should not frequently freeze or become heavily laggy on a Windows 11 Pro machine with 32 GB RAM and a Ryzen 5 5600 CPU. ### Additional information This issue occurs even when Windows Task Manager shows that RAM is not fully used. Other applications remain responsive, so the bottleneck appears to be inside the Codex App rather than the whole system. I am using the latest Codex App version available from the Microsoft Store. My hardware should be more than sufficient for normal local app usage, so I believe this may be a Windows performance/optimization issue in the Codex App.", "url": "https://github.com/openai/codex/issues/20214", "createdAt": "2026-04-29T14:27:53Z", "updatedAt": "2026-08-12T20:30:53Z", "timestamp": "2026-08-12T20:30:53Z", "metrics": { "reactions": 82, "comments": 97 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "squarepots", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/20214", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-2bd87eae9e76" }, { "tier": "triage-lead", "rankScore": 43, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:25719", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex Desktop: 26.527.60818 Codex build: 3437 ### What subscription do you have? plus ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch. With Codex closed, the system is quiet. As soon as Codex Desktop is opened, `/usr/libexec/syspolicyd` rises to very high CPU usage and grows to multiple GB of RAM. This happens even after replacing Codex with a freshly downloaded DMG build. This appears related to Codex Desktop launching or validating its bundled/helper components, including `Codex Computer Use`, but the problem also reproduces after user-facing Browser/hotkey/notify settings were disabled. ### What steps can reproduce the bug? ## Reproduction steps 1. Boot macOS normally. 2. Ensure Codex Desktop is closed. 3. Observe Activity Monitor: CPU is normal. 4. Run: ```bash sudo killall -9 syspolicyd trustd ``` 5. Confirm CPU is still normal. 6. Open Codex Desktop. 7. Observe `syspolicyd` rising to very high CPU and memory usage. The same pattern was observed after manually replacing Codex with the latest freshly downloaded DMG build. ### What is the expected behavior? _No response_ ### Additional information # Bug Report: Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway ## Summary Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch. With Codex closed, the system is quiet. As soon as Codex Desktop is opened, `/usr/libexec/syspolicyd` rises to very high CPU usage and grows to multiple GB of RAM. This happens even after replacing Codex with a freshly downloaded DMG build. This appears related to Codex Desktop launching or validating its bundled/helper components, including `Codex Computer Use`, but the problem also reproduces after user-facing Browser/hotkey/notify settings were disabled. ## Environment ```text Device: Apple Silicon MacBook Air, M5 macOS: 26.5 Build: 25F71 Codex Desktop: 26.527.60818 Codex build: 3437 Timezone: Europe/Rome Date observed: 2026-06-01 / 2026-06-02 ``` Previous Codex version also affected: ```text Codex Desktop: 26.527.31326 Build: 3390 ``` ## Main symptom When Codex is closed: ```text CPU usage is normal. Activity Monitor is quiet. syspolicyd / trustd are not consuming significant resources. ``` When Codex is opened: ```text /usr/libexec/syspolicyd immediately rises to very high CPU usage. CPU observed: approximately 125% to 200%. Memory observed: over 8 GB RSS in one run. trustd also becomes active. ``` Example captured after launching Codex build 3437: ```text %CPU PID %MEM RSS COMMAND 125.7 29702 34.0 8549776 /usr/libexec/syspolicyd 11.3 29728 3.0 756064 /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled 11.1 29701 1.9 471728 /Applications/Codex.app/Contents/MacOS/Codex 6.5 29699 0.1 16800 /usr/libexec/trustd ``` ## User-visible Gatekeeper dialog The user repeatedly sees: ```text \"Codex Computer Use\" is damaged and can't be opened. You should move it to the Trash. This file was downloaded on an unknown date. ``` The app named in the dialog is: ```text /Users/mgair/.codex/computer-use/Codex Computer Use.app ``` ## Important verification The affected helper app does not appear to be actually corrupt. It was checked locally: ```text codesign verification: valid on disk Developer ID: OpenAI OpCo, LLC TeamIdentifier: 2DC432GLL2 Notarization ticket: stapled ``` `cmux.app`, another unrelated notarized app, is accepted by Gatekeeper when `syspolicyd` is not wedged: ```text /Applications/cmux.app: accepted source=Notarized Developer ID ``` This suggests the issue is not a generally unsigned or damaged app problem. It looks like `syspolicyd` enters a bad state after Codex Desktop starts. ## Reproduction steps 1. Boot macOS normally. 2. Ensure Codex Desktop is closed. 3. Observe Activity Monitor: CPU is normal. 4. Run: ```bash sudo killall -9 syspolicyd trustd ``` 5. Confirm CPU is still normal. 6. Open Codex Desktop. 7. Observe `syspolicyd` rising to very high CPU and memory usage. The same pattern was observed after manually replacing Codex with the latest freshly downloaded DMG build. ## Workarounds attempted ### 1. Increase open file limit The system `maxfiles` limit was increased: ```text maxfiles 65536 unlimited ``` This did not fix the issue. ### 2. Disable Codex Computer Use / Browser / hotkey hooks in user config Current config state: ```toml notify = [] [plugins.\"browser@openai-bundled\"] enabled = false ``` Current keybindings: ```json [] ``` Current global hotkey state: ```json \"globalDictationToggleHotkey\": null \"appshotHotkey\": null ``` The config files were temporarily protected from silent rewrites using `uchg`. Despite this, after launching Codex Desktop, these processes still appeared: ```text /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/.../SkyComputerUseClient turn-ended --previous-notify [] ``` This suggests Codex Desktop may be launching `Codex Computer Use` outside the user-visible config path, or the desktop process may have a separate internal integration path. ### 3. In-app update The in-app Sparkle update previously failed: ```text SUSparkleErrorDomain Code=4005 \"An error occurred while starting the installer. Please try again later.\" ``` Manual DMG replacement succeeded, but did not resolve the issue. ## Additional concern One stale `SkyComputerUseClient turn-ended` process was observed with a very large serialized conversation payload in its command-line arguments. That command line appeared to include extensive thread context. This may be relevant if the helper is being repeatedly assessed or launched with very large arguments. For privacy, the full command line is not included here, but it was clearly visible in `pgrep -alf` output. ## Expected behavior Opening Codex Desktop should not cause: - `syspolicyd` to consume 100-200% CPU. - `syspolicyd` to grow to multi-GB memory use. - Gatekeeper to show `\"Codex Computer Use\" is damaged`. - unrelated notarized apps to become hard to open while `syspolicyd` is wedged. ## Actual behavior Codex launch reliably causes `syspolicyd` and sometimes `trustd` to spike. Closing Codex and killing `syspolicyd` / `trustd` calms the system. Reopening Codex reproduces the issue. ## User impact This caused hours of troubleshooting, repeated reboots including Safe Mode attempts, broken/blocked app launches while `syspolicyd` was wedged, and significant Codex usage spent diagnosing the Codex Desktop bug itself. ## Update: Reinstall / macOS 26.5.1 Did Not Fix It The user reinstalled/updated macOS and retested. Current system after reinstall/update: ```text macOS: 26.5.1 Build: 25F80 Codex Desktop: 26.527.60818 Codex build: 3437 ``` Result: the issue still reproduces. Before launching Codex, `fileproviderd` was already using high CPU, likely due to iCloud/File Provider resync after the reinstall. However, `syspolicyd` spiked specifically after Codex was launched. Example after launching Codex on macOS 26.5.1: ```text %CPU PID %MEM RSS COMMAND 106.3 668 4.6 1164208 /usr/libexec/syspolicyd 89.7 1190 0.5 120336 /System/Library/PrivateFrameworks/FileProvider.framework/Support/fileproviderd 11.4 2827 1.9 488912 /Applications/Codex.app/Contents/MacOS/Codex 7.0 601 0.1 19808 /usr/libexec/trustd 0.0 3097 0.5 114592 /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService ``` Important: the Codex config files still showed: ```text notify = [] Browser plugin disabled keybindings = [] globalDictationToggleHotkey = null appshotHotkey = null config files protected with uchg ``` Despite that, Codex Desktop still launched: ```text /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService ``` Additional observation on macOS 26.5.1: the `syspolicyd` CPU usage is not just a short startup spike. It can drop temporarily and then rise again. One later sample showed: ```text %CPU PID %MEM RSS ELAPSED COMMAND 181.6 668 7.4 1858064 19:03 /usr/libexec/syspolicyd ``` At that later point, the `SkyComputerUseService` process was no longer visible in the process list, but `syspolicyd` was still consuming very high CPU. This suggests the system policy loop may continue after the helper process exits or disappears. Conclusion after this update: the issue is unlikely to be local corruption of Gatekeeper/SystemPolicy databases. It appears to be a reproducible Codex Desktop/macOS 26.5.x integration problem, and Codex Desktop appears to launch `Codex Computer Use` even when the visible user config disables the related hooks. ## Request Please escalate this to the Codex Desktop/macOS team. Please also consider a goodwill account credit, usage refund, or temporary upgrade for the affected user, since substantial paid usage was consumed diagnosing what appears to be a Codex Desktop/macOS integration bug rather than the user's requested work. Suggested account-facing wording: ```text I spent substantial paid Codex usage diagnosing a reproducible Codex Desktop bug on macOS where launching Codex causes syspolicyd/trustd CPU and memory runaway. Please consider restoring the consumed usage or providing a temporary upgrade/credit while this is investigated. ``` ## Attachments / useful local file Detailed local troubleshooting notes: ```text /Users/mgair/Documents/New project/Codex_Gatekeeper_Workaround_2026-06-01.md ```", "url": "https://github.com/openai/codex/issues/25719", "createdAt": "2026-06-01T23:59:29Z", "updatedAt": "2026-08-13T08:23:26Z", "timestamp": "2026-08-13T08:23:26Z", "metrics": { "reactions": 445, "comments": 84 }, "labels": [ "bug", "app", "computer-use", "performance" ], "author": "energissimo-mg", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/25719", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-5c18d2c37be5" }, { "tier": "triage-lead", "rankScore": 43, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:28969", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add setting to disable the auto-resolve in 60 seconds for questions", "text": "### What version of Codex CLI is running? codex-cli 0.141.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.5 ### What platform is your computer? Linux 7.0.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 01 May 2026 15:49:22 +0000 x86_64 GNU/Linux ### What terminal emulator and version are you using (if applicable)? Alacritty ### Codex doctor report ```json not available ``` ### What issue are you seeing? Codex will automatically accept the recommended answer to a question within 60 seconds. ### What steps can reproduce the bug? 1. Go to plan mode 2. Write a plan prompt that will make Gpt to ask you a question 3. Notice you have a 60 second delay to answer the question ### What is the expected behavior? There should be a setting to disable the 60-second auto-resolving. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/28969", "createdAt": "2026-06-18T19:54:02Z", "updatedAt": "2026-08-13T11:33:08Z", "timestamp": "2026-08-13T11:33:08Z", "metrics": { "reactions": 198, "comments": 72 }, "labels": [ "bug", "CLI", "config", "plan" ], "author": "antoyo", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/28969", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-66a343b527ca" }, { "tier": "triage-lead", "rankScore": 43, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:31606", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Reset failed, did not apply and 1 reset is wasted", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.623.141536 ### What subscription do you have? Pro ### What platform is your computer? Windows ### What issue are you seeing? I used one of my resets and it did not apply and my reset counter dropped from 2 to 1, I did not hit the reset button again worrying that i would loose that reset too. I value my resets because my project depends on it. Can you give the reset back please. and also fix the error because time is running outttttt. Love codex though hehe ### What steps can reproduce the bug? just hit the use reset option ### What is the expected behavior? failed reset or the reset being not applied ### Additional information The usage meter has been buggy since 12 hrs ago for me", "url": "https://github.com/openai/codex/issues/31606", "createdAt": "2026-07-08T17:02:50Z", "updatedAt": "2026-08-13T01:47:12Z", "timestamp": "2026-08-13T01:47:12Z", "metrics": { "reactions": 69, "comments": 56 }, "labels": [ "bug", "rate-limits", "app" ], "author": "otpl8855-hash", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/31606", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-59352f2a08a1" }, { "tier": "triage-lead", "rankScore": 43, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:8648", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex replies to earlier messages instead of latest one in conversations", "text": "### What version of Codex is running? 0.77.0 ### What subscription do you have? Pro ### Which model were you using? gpt-5.2-xhigh ### What platform is your computer? _No response_ ### What issue are you seeing? In multi-message conversations with Codex, the assistant sometimes responds to an earlier message instead of the most recent one. For example, I had a conversation with six messages. By the sixth message, I had moved on to asking a different question, but Codex's final summary acted as if it was still on the third message. The third message asked about a question A and its solution, while the sixth asked about question B. Even though the topic changed at the sixth message, Codex still responded about question A. This happens frequently and suggests that Codex may be referencing the wrong message in the conversation history. ### What steps can reproduce the bug? 1. Start a conversation in Codex and send several messages (e.g., six messages). 2. In an earlier message (e.g., the third message), ask question A and wait for a response. 3. In a later message (e.g., the sixth message), ask a different question B. 4. Observe that Codex's summary or response refers back to question A rather than answering question B. This suggests that Codex is using the wrong message as context. ### What is the expected behavior? Codex should respond to the current message, acknowledging the latest context. After a user moves from question A to question B, the assistant should answer question B and not revert to a previous question. The summarization should maintain the correct message pointer in the conversation. ### Additional information the pattern is randomly happening, and it has a higher chance to happen after we compacting the context within the conversation", "url": "https://github.com/openai/codex/issues/8648", "createdAt": "2026-01-01T08:28:24Z", "updatedAt": "2026-08-12T14:38:38Z", "timestamp": "2026-08-12T14:38:38Z", "metrics": { "reactions": 58, "comments": 83 }, "labels": [ "bug", "context", "agent" ], "author": "BobbyWang0120", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/openai/codex/issues/8648", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-5f59c42acc0d" }, { "tier": "triage-lead", "rankScore": 42, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:65833", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "v2.1.150: scroll wheel no longer scrolls conversation — sends arrow keys instead", "text": "## Bug description After updating to v2.1.150, the mouse scroll wheel no longer scrolls through the conversation output inside the Claude Code TUI. Instead, it sends arrow keys, which cycles through input history in the prompt field. Previously (before v2.1.150), scroll wheel worked correctly to scroll up/down through the conversation. A message appears at the bottom of the UI: **\"Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll\"** — confirming this is intentional in the new version, but it's a significant UX regression. ## Environment - Claude Code version: v2.1.150 - OS: Windows 11 + WSL2 (Ubuntu) - Terminal: PyCharm embedded terminal (`wsl.exe --distribution Ubuntu`) ## Expected behavior Mouse scroll wheel scrolls through conversation output, with a visible scrollbar on the right side of the terminal panel (as it did before v2.1.150). ## Actual behavior Scroll wheel sends arrow keys (navigates input history). No scrollbar visible. Must use PgUp/PgDn to scroll, which is unintuitive and breaks the previous workflow. ## Request Please restore mouse scroll wheel support for scrolling conversation output, or make it configurable.", "url": "https://github.com/anthropics/claude-code/issues/65833", "createdAt": "2026-06-06T09:39:05Z", "updatedAt": "2026-08-13T16:25:01Z", "timestamp": "2026-08-13T16:25:01Z", "metrics": { "reactions": 90, "comments": 37 }, "labels": [ "bug", "area:tui", "regression", "platform:wsl" ], "author": "tatuliusi", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/65833", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-f9b48de634ac" }, { "tier": "triage-lead", "rankScore": 41, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:25090", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Renamed session works on first resume but the name disappears after the second exit", "text": "### Preflight Checklist - [x] I have searched existing issues and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When I rename a session using `/rename`, it works perfectly fine the first time I resume it. But after I continue chatting in that resumed session and exit again, the name I gave it just vanishes. The session goes back to some auto generated name and I can no longer find it using the custom name I set. So basically the rename only sticks for one round. After the second exit, the system seems to replace my custom name with its own auto generated title. This is confusing because the first time it works, so you think everything is fine, but then it silently breaks on the next attempt. This is not the same as rename failing to persist at all (like #24065 or #23422). In my case the rename does persist and the first resume works. The problem is that the auto naming kicks in during the second session save and overwrites whatever I named it. ### What Should Happen? Once I rename a session, that name should stay permanently. It should not matter how many times I exit and come back to it. If I named it \"my-project\", it should always show up as \"my-project\" in the resume list every single time. ### Error Messages/Logs ``` No specific error message. The session just does not show up under the custom name in the resume picker on the second attempt. It is still there somewhere but under a random auto generated slug that I cannot identify. ``` ### Steps to Reproduce 1. Start a new session with `claude` 2. Send a few messages to have some conversation going 3. Rename the session using `/rename my-project` 4. Confirm it shows the success message 5. Exit the session using `/exit` 6. Resume it with `claude --resume my-project` and it works perfectly fine 7. Send a few more messages in the resumed session 8. Exit again using `/exit` 9. Now try `claude --resume my-project` again 10. This time it cannot find the session. The custom name is gone. ### Claude Model Opus 4.6 ### Environment - Claude Code version: 2.1.39 - Platform: Windows 11 Pro (10.0.26200) - Terminal: Windows Terminal ### Additional Context This is reproducible 100% of the time. Every session I rename goes through the same pattern. First resume works, second one loses the name. It looks like the auto titling logic runs again when a resumed session gets saved and it does not check if the user has already given it a custom name.", "url": "https://github.com/anthropics/claude-code/issues/25090", "createdAt": "2026-02-11T20:30:55Z", "updatedAt": "2026-08-13T04:55:19Z", "timestamp": "2026-08-13T04:55:19Z", "metrics": { "reactions": 29, "comments": 33 }, "labels": [ "bug", "has repro", "platform:windows", "area:tui", "area:core" ], "author": "ascender1729", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/25090", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-1180b2cc4539" }, { "tier": "triage-lead", "rankScore": 41, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:39523", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[META] Bypass permissions mode is fundamentally broken — 9-month trail, 12+ duplicates, no resolution", "text": "# [META] Bypass permissions mode is fundamentally broken — 9-month trail, 12+ duplicates, no resolution ## Summary `bypassPermissions` mode does not bypass permissions. This has been broken in various forms since **July 2025** (#2933) and remains broken on **v2.1.84** (March 2026). The only official response was \"Fix incoming\" on #35646 (March 20) — the issue was closed, but the fix didn't hold. Users on v2.1.84 confirm the problem persists. This meta-issue maps the full dependency tree to give the team a single place to track the problem instead of playing whack-a-mole with duplicates. ## Two correlated failure branches ### Branch 1: Protected directories ignore bypass mode (v2.1.78 regression) v2.1.78 introduced hardcoded protection for `.claude/`, `.git/`, `.vscode/`, and `.idea/` directories that overrides every bypass mechanism: - ✗ `--dangerously-skip-permissions` CLI flag - ✗ `permissions.defaultMode: \"bypassPermissions\"` in settings - ✗ `claudeCode.initialPermissionMode: \"bypassPermissions\"` in VSCode settings - ✗ PreToolUse hooks returning `permissionDecision: \"allow\"` - ✗ Broad wildcards in the `allow` list (`Edit(.claude/**)`, `Write(.claude/**)`) | Issue | Title | Status | Date | |-------|-------|--------|------| | #36044 | Feature request: opt-in full bypassPermissions for protected directories | **OPEN** | 2026-03-19 | | #36282 | Protected directories not writable in bypassPermissions mode | **OPEN** | 2026-03-19 | | #35646 | v2.1.78: Protected directory prompt has no override | closed (fix regressed) | 2026-03-18 | | #35718 | --dangerously-skip-permissions doesn't bypass ~/.claude/ writes | closed | 2026-03-18 | | #37765 | .claude/ directory writes prompt despite bypass | **OPEN** | 2026-03-23 | | #37836 | Allow configuring protected directories in bypass mode | **OPEN** | 2026-03-23 | | #36887 | Permissions repeatedly requested despite bypass enabled | **OPEN** | 2026-03-21 | | #37181 | Edit tool prompts despite bypassPermissions + --dangerously-skip-permissions | **OPEN** | 2026-03-21 | ### Branch 2: Permission mode resets mid-session The permission mode spontaneously downgrades from \"Bypass permissions\" to \"Edit automatically\" during a session. Clicking \"Yes, allow all edits this session\" on a protected directory prompt triggers the downgrade. This has been reported since v0.2.x (May 2025) and persists through v2.1.84. | Issue | Title | Status | Date | |-------|-------|--------|------| | **#2933** | **VS Code Extension ignores global dangerously-skip-permissions** | **OPEN** | **2025-07-03** | | #1014 | Bypassing Permissions is broken again | closed | 2025-05-08 | | #36473 | Mode spontaneously switches from bypass to 'accept edits' | closed | 2026-03-20 | | #32559 | --dangerously-skip-permissions doesn't suppress prompts | **OPEN** | 2026-03-09 | | #39350 | Bypass mode resets on every edit | **OPEN** | 2026-03-26 | | #39057 | Mode resets from Bypass to Edit automatically mid-session | **OPEN** | 2026-03-26 | | #38543 | Bypass mode still prompts for every edit on Windows | **OPEN** | 2026-03-25 | | #38148 | Desktop Code tab ignores bypass mode | **OPEN** | 2026-03-24 | ## Timeline - **2025-05-08** — #1014: \"Bypassing Permissions is broken again\" (v0.2.104) - **2025-07-03** — #2933: VSCode extension ignores bypass (v1.0.40). **Still open. No Anthropic response. 9 months old.** - **2026-03-09** — #32559: --dangerously-skip-permissions doesn't suppress prompts (v2.1.80) - **2026-03-18** — #35646: v2.1.78 introduces protected directory prompts in bypass mode - **2026-03-20** — @bcherny comments \"Fix incoming\" on #35646. Issue closed. - **2026-03-21** — #36887: Users confirm fix didn't work (v2.1.81) - **2026-03-26** — #39350, #39057: Still broken on v2.1.84. Mode still resets mid-session. ## What users need 1. **`bypassPermissions` should mean bypass.** If I've opted into the mode with the scary name, I've accepted the risk. Don't second-guess me for `.claude/` subdirectories. 2. **At minimum, let us configure exemptions.** A setting like `bypassProtectedPaths: [\".claude/hooks/\", \".claude/skills/\"]` would solve 90% of the pain for power users with agent workflows. 3. **Stop the mode downgrade.** Responding to any permission prompt should not change the active permission mode from Bypass to Edit Automatically. ## Environment - Claude Code v2.1.84 - VSCode extension on Linux (Ubuntu 24.04) - `claudeCode.allowDangerouslySkipPermissions: true` - `claudeCode.initialPermissionMode: \"bypassPermissions\"` - Extensive hook and agent workflows that touch `.claude/hooks/` and `.claude/skills/` cc @bcherny — this has been open in various forms for 9 months. The \"fix incoming\" on #35646 didn't resolve it. Could this get prioritised?", "url": "https://github.com/anthropics/claude-code/issues/39523", "createdAt": "2026-03-26T19:19:44Z", "updatedAt": "2026-08-13T16:09:36Z", "timestamp": "2026-08-13T16:09:36Z", "metrics": { "reactions": 18, "comments": 34 }, "labels": [ "bug", "area:permissions" ], "author": "interconnectedMe", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/39523", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-05ccdb369735" }, { "tier": "triage-lead", "rankScore": 40, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:29017", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Conversation history is lost in VSCode extension", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Using VSCode extension, conversation history disappears. In the most recent instance, had long conversation, closed the chat tab, re-opened it, and only part of the messages were present. It's the integrated chat tab, not the terminal ### What Should Happen? Conversation history should not be lost. ### Error Messages/Logs ```shell N/A ``` ### Steps to Reproduce Just use the VSCode Extension, the problem is recurrent. ### Claude Model Sonnet (default) ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.59 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell VS Code integrated terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/29017", "createdAt": "2026-02-26T14:26:16Z", "updatedAt": "2026-08-13T13:29:43Z", "timestamp": "2026-08-13T13:29:43Z", "metrics": { "reactions": 23, "comments": 29 }, "labels": [ "bug", "platform:macos", "area:ide", "platform:vscode" ], "author": "I571664", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/29017", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-a2c358d109de" }, { "tier": "triage-lead", "rankScore": 40, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:62466", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Repeated \"Image couldn't be processed\" API errors consuming usage limit in Claude Code", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Description Claude Code repeatedly triggered image processing errors that consumed my entire usage limit without producing useful output. After an initial failed attempt to process a base64-encoded image, every subsequent request in the conversation triggered the same error. ## Error Pattern The following error appeared on every tool invocation after the initial failure: An image couldn't be read. Rewind to remove it and try a different format. API Error: an image in the conversation could not be processed and was removed. Re-read the file with a different approach if you still need it. Tool calls that triggered the error: - Read bg66xakij.output - ToolSearch - Generic tool usage - \"Verify image then send all preview emails\" - \"Follow redirect to confirm 200\" ## Actual Behavior The error persisted across all subsequent requests, consuming my entire 5-hour usage limit without producing useful work. ## Environment - Product: Claude Code Desktop MacOS - Conversation ID: 215474449845617 - Date: May 26, 2026 - MacOS Version 26.3.1 (a) (25D771280a) Claude desktop version: \"May 22, 2026 1.8555.1\" ## Impact This bug consumed my entire usage allocation, preventing me from completing my work. ### What Should Happen? ## Expected Behavior After an image processing error, Claude Code should either: - Stop attempting to process the problematic image - Allow the conversation to continue without repeatedly triggering the same error - Not consume usage credits for repeated error states ### Error Messages/Logs ```shell Image couldn't be processed An image couldn't be read. Rewind to remove it and try a different format. View details API Error: an image in the conversation could not be processed and was removed. Re-read the file with a different approach if you still need it. ``` ### Steps to Reproduce ## Steps to Reproduce 1. Asked Claude Code to append an image to an email template 2. Claude Code attempted to read base64-encoded image from `/tmp/barberas-email/logo-base64.txt` 3. Initial commands executed: - `cat /tmp/barberas-email/logo-base64.txt | wc -c` (returned 2098) - `cat /tmp/barberas-email/logo-base64.txt | head -c 100 && echo \"...\"` 4. Received error: \"API Error: an image in the conversation could not be processed and was removed\" 5. Every subsequent request triggered the same error repeatedly ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.140 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information \"Image\" \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/62466", "createdAt": "2026-05-26T11:47:17Z", "updatedAt": "2026-08-13T03:08:07Z", "timestamp": "2026-08-13T03:08:07Z", "metrics": { "reactions": 21, "comments": 31 }, "labels": [ "bug" ], "author": "3ct0s", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/62466", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-d8d538e6a85b" }, { "tier": "triage-lead", "rankScore": 40, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:28919", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex app missing “\\control other devices\"” tab in Settings > Connections", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.611.62324 • Released Jun 17, 2026 ### What subscription do you have? Pro ### What platform is your computer? `Microsoft Windows NT 10.0.26200.0 x64` ### What issue are you seeing? I want to control codex remotely from my windows pc, under the connections tab the \"control other devices\" tab is missing. Displayed are \"control this pc\" and \"ssh\" ### What steps can reproduce the bug? Opening the connection settings ### What is the expected behavior? control other devices tab being displayed and I can control ### Additional information \"Image\"", "url": "https://github.com/openai/codex/issues/28919", "createdAt": "2026-06-18T14:02:04Z", "updatedAt": "2026-08-13T07:43:38Z", "timestamp": "2026-08-13T07:43:38Z", "metrics": { "reactions": 33, "comments": 31 }, "labels": [ "bug", "windows-os", "app", "remote" ], "author": "zi070410", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/28919", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-b51e565abd0f" }, { "tier": "triage-lead", "rankScore": 39, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:24798", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Inter-session communication for multi-Claude workflows", "text": "## Feature Request **Direct project workflow between siloed Claude sessions to sequence higher level processes with dependencies.** ### Problem When working on a large project, users run multiple Claude Code sessions in parallel — each focused on a different module or task. These sessions are completely siloed with no way to communicate, share state, or coordinate. Today I'm running 5 concurrent Claude sessions: - One doing a **server migration** (Lightsail → EC2) - One working on **database/taxonomy** changes - One building a **search module** - One on **card design/KPI dashboards** - One as a **terminal monitor** (health checks, backups, handoffs) The migration session is changing the server IP, certificates, and service configs. Every other session still has the old IP hardcoded in its context. There is no way for the migration session to notify the others. I have to manually relay information between sessions — copy-pasting context, writing handoff documents to disk, and verbally telling each Claude what the others are doing. ### What Would Help 1. **Inter-session messaging** — One session sends a message to another (by session ID or name). \"Hey Taxonomy-DB, the server IP changed to X.X.X.X\" 2. **Shared project scratchpad** — A key-value store all sessions in the same project can read/write. Migration writes `SERVER_IP=50.19.186.215`, all sessions pick it up. 3. **Event/notification bus** — Sessions subscribe to events. \"When migration completes, notify all sessions to update configs.\" 4. **Dependency sequencing** — Define that Task B (deploy app) depends on Task A (migration complete). Claude sessions coordinate automatically. 5. **Delegation** — One session hands a subtask to another session that has the right context for it. ### Current Workarounds (all terrible) - **File-based handoffs** — Write markdown docs to disk, tell the other session to read them. Slow, manual, loses context. - **Health monitor scripts** — Background bash scripts checking session file sizes, writing to log files. Fragile. - **User as message bus** — I copy-paste between sessions. Defeats the purpose of parallel agents. ### Real-World Impact Sessions die from context bloat (I've lost 3 sessions today at 55-62 MB). When a session dies, the replacement has zero knowledge of what the other sessions are doing. A shared state layer would let new sessions bootstrap instantly. This would turn Claude Code from \"multiple independent assistants\" into an actual coordinated team. ### Related - #24709 — Session identification (persistent names, visible IDs) --- *Filed from a terminal Claude session currently acting as coordinator/monitor across 5 active project sessions. The irony of not being able to just tell the other Claudes directly is not lost on me.*", "url": "https://github.com/anthropics/claude-code/issues/24798", "createdAt": "2026-02-10T20:28:15Z", "updatedAt": "2026-08-13T16:42:27Z", "timestamp": "2026-08-13T16:42:27Z", "metrics": { "reactions": 21, "comments": 65 }, "labels": [ "enhancement", "area:tui", "area:core" ], "author": "hmcg001", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/24798", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-44e7d9495d07" }, { "tier": "triage-lead", "rankScore": 39, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:50246", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Feature Request: Message queue mode — queue messages instead of interrupting active tasks", "text": "## Problem When Claude is actively working on a task, the only option is to interrupt it. If I think of a follow-up mid-task I either have to interrupt and potentially derail the current work, or try to remember it until Claude finishes. ## Proposed Solution Add a **message queue mode** alongside the existing interrupt behavior: - A toggle or modifier (e.g. Shift+Enter, or a dedicated queue button) that sends the message to a queue instead of interrupting - Claude finishes its current task, then automatically picks up the queued message in order - User can choose between two modes: - **Interrupt** (current behavior) — sends immediately, stops current task - **Queue** (new) — holds the message, delivered automatically when the current task completes ## Why It Matters Long-running tasks (builds, encodes, multi-step workflows) are common in Claude Code. A queue lets users capture follow-up thoughts as they happen without derailing active work. It also enables a more natural async workflow where the user stays in flow rather than waiting and watching for task completion before typing the next thing. ## UX Suggestion A small queue indicator near the input box showing pending messages would give confidence that the queued message was captured and will be acted on.", "url": "https://github.com/anthropics/claude-code/issues/50246", "createdAt": "2026-04-18T02:44:26Z", "updatedAt": "2026-08-13T17:31:09Z", "timestamp": "2026-08-13T17:31:09Z", "metrics": { "reactions": 224, "comments": 55 }, "labels": [ "enhancement", "area:tui" ], "author": "mozltovcoktail", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/50246", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-73e157929f53" }, { "tier": "triage-lead", "rankScore": 39, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:51828", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Scrollback duplication on terminal resize persists in 2.1.116 (VS Code integrated terminal, macOS)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Update (2026-04-26) This issue was originally filed against macOS + VS Code, but reports in this thread confirm it is **not platform-specific** and **not VS Code-specific**. Reframing scope and consolidating findings at the top. Original report preserved below. ### Confirmed reproductions - macOS + VS Code integrated terminal (original report, also @Danielevko) - Linux + tmux + alacritty (@napter) - Linux + tmux + kitty (@igor47) - Linux + tmux + xterm.js web client (@eyalev) - Windows Terminal, legacy `conhost.exe`, Linux Mint + gnome-terminal (@NatanaelRibF) - Windows, generic (@cesarvarela) ### Regression bisected to 2.1.101 @eyalev ran a deterministic harness across every native build on `downloads.claude.ai` from 2.1.100 → 2.1.119: | Version | Leak count on 6 resizes | |---------|--------------------------| | 2.1.100 | 0 (clean) | | 2.1.101 | 6 (regression lands) | | 2.1.116 | 6 (claimed fix — unchanged) | | 2.1.119 | 6 (current) | The 2.1.116 changelog entry \"Fixed scrollback duplication\" does not address this variant. Last known-good version is **2.1.100 (2026-04-10)**. ### Triggers (broader than resize) The duplication fires on *any* main-screen redraw event, not just SIGWINCH: - Terminal resize - Output bursts that exceed pane height - `※ recap:` away-summary block rendering on session resume - Input prompt state transitions (e.g. vim-mode `-- INSERT --` indicator appearing/disappearing) ### Suspected cause (per @napter) Ink's redraw emits cursor-up + erase-line to rewind over the previous frame. When the dynamic region is taller than the viewport, cursor-up saturates at the top of the viewport — content that has already scrolled off cannot be erased. The next frame appends at the bottom and pushes one pane-height of un-erased content into scrollback. N redraws → N duplicates, spaced by pane height. Full-height panes that fit the entire dynamic region do not duplicate, consistent with the saturation theory. ### Workarounds, ranked | Workaround | Effect | Cost | |---|---|---| | Downgrade to 2.1.100 | Fully clean | Lose newer features | | `\"tui\": \"fullscreen\"` in `~/.claude/settings.json` | Eliminates leak (alt-screen renderer doesn't touch scrollback) | Laggier line-by-line scrolling, no native scrollback | | `\"awaySummaryEnabled\": false` | Removes the recap trigger only | Doesn't fix resize or large-output triggers | ### Confirmed *not* to help - VS Code GPU acceleration / `useAtlasEngine: false` on Windows Terminal - Shell choice (zsh / bash / pwsh / cmd / Git Bash) - Shell integration on/off - Custom statusLine on/off - `editorMode` (vim vs normal) - Font ligatures, integer fontSize, zero letterSpacing - Scrollback buffer size - Terminal smoothing / accessibility settings ### Related issues #51418, #46834, #52825, #52924, #52027, #52547, #52124 ### Ask - Re-triage as cross-platform (remove platform-specific labels) - Reopen if closed against the 2.1.116 fix - Diff 2.1.100 → 2.1.101 in the Ink / main-screen renderer path --- ## Original report The scrollback duplication on resize bug noted as fixed in v2.1.116 still reproduces in my environment. Each terminal resize during a Claude Code session pushes a full snapshot of the current TUI into terminal scrollback. Multiple resizes produce stacked duplicates of the splash screen / current view. The fix from v2.1.116 (\"Fixed scrollback duplication in inline mode where resizing the terminal or large output bursts would repeat earlier conversation history\") appears to be incomplete for this environment combination. Likely related to / possible duplicate of #18493. ## Environment - Claude Code: 2.1.116 - VS Code: 1.116.0 (integrated terminal, panel location) - OS: macOS 26 (Darwin 25.4.0) - Hardware: Apple Silicon - Shell: zsh (default macOS, minimal `.zshrc` — PATH exports only, no custom prompt) - Terminal font: JetBrainsMono Nerd Font Mono - TUI mode: `default` (the bug does not occur with `tui: \"fullscreen\"`) ### What Should Happen? **Expected:** Scrollback shows whatever was in the shell before `claude` was launched. ### Error Messages/Logs ```shell **Actual:** Scrollback contains multiple stacked duplicates of the Claude splash screen, separated by stray characters (e.g. `)`). The bug appears on the splash screen with zero user input, ruling out hooks, statusline, or any per-turn behavior. ``` ### Steps to Reproduce ## Reproduction 1. Open VS Code integrated terminal 2. Run `claude` to start a fresh session 3. **Before sending any prompt**, resize the terminal panel several times (drag the panel border, or toggle panel maximize) 4. Scroll up in the terminal Cross-platform reproducer (per @napter, Linux + tmux): 1. Split a tmux pane so Claude Code runs in a pane ~50 lines tall 2. Prompt a response that emits long tool-call output (e.g. a git commit with a HEREDOC message ≥60 lines, or a large diff) 3. `tmux capture-pane -p -S -50000` after the response completes — same content block repeats at intervals matching pane height ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.100 (regression introduced in 2.1.101, 2026-04-10) ### Claude Code Version 2.1.116 (also reproduced on 2.1.117, 2.1.118, 2.1.119) ### Platform Anthropic API ### Operating System macOS (also reproduced on Linux and Windows — see Update section above) ### Terminal/Shell VS Code integrated terminal (also reproduced in alacritty, kitty, Windows Terminal, conhost, gnome-terminal, xterm.js) ### Additional Information ## Workaround Setting `\"tui\": \"fullscreen\"` in `~/.claude/settings.json` eliminates the glitch (alt-screen renderer doesn't touch scrollback). However, scrolling inside fullscreen mode is line-by-line and feels noticeably laggier than native xterm.js scrolling, so it isn't a comfortable permanent solution for heavy terminal users. The cleanest workaround is downgrading to 2.1.100 until the renderer regression is addressed. ## Ruled out (not the cause) Exhaustively eliminated as causes across multiple reporters and platforms: - VS Code `terminal.integrated.gpuAcceleration` (`on`, `off`, `auto` — same) - VS Code `terminal.integrated.shellIntegration` (disabled — same) - VS Code `terminal.integrated.suggest.enabled` (disabled — same) - VS Code `terminal.integrated.stickyScroll.enabled` (disabled — same) - VS Code `terminal.integrated.smoothScrolling` (disabled — same) - VS Code `terminal.integrated.minimumContrastRatio` (removed — same) - VS Code `terminal.integrated.scrollback` (varied 1000–20000 — only changes how long duplicates persist before aging out) - VS Code `editor.accessibilitySupport: \"on\"` (set to `off` — same) - Windows Terminal `useAtlasEngine: false` (same) - Terminal font (swapped to Menlo — same) - Shell choice (zsh / bash / pwsh / cmd / Git Bash — same) - Custom statusline (removed — same) - `editorMode` (vim vs normal — same) - Custom hooks (logically excluded — they fire on `Stop`/`Notification`, but the bug appears pre-turn) - Plain `zsh` (no Claude) — resize + scroll works perfectly with all the above settings unchanged ## Notes for triage The bug only manifests when Claude Code is the running process. Same terminal config + same shell with anything else (vim, less, plain zsh) behaves correctly. The leak is in Claude Code's main-screen renderer's response to redraw events (SIGWINCH, large output, recap render, prompt-state transitions) — not in the host terminal or the shell.", "url": "https://github.com/anthropics/claude-code/issues/51828", "createdAt": "2026-04-22T04:02:05Z", "updatedAt": "2026-08-13T05:41:06Z", "timestamp": "2026-08-13T05:41:06Z", "metrics": { "reactions": 33, "comments": 25 }, "labels": [ "bug", "has repro", "area:tui" ], "author": "r1ckrck", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/51828", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-00f3ef1c304a" }, { "tier": "triage-lead", "rankScore": 39, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:34260", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop: unbounded taskkill.exe/conhost.exe cleanup storm exhausts WMI", "text": "## Summary Codex Desktop on Windows can enter an unbounded process-cleanup loop where hundreds of `taskkill.exe` processes remain alive, each with a corresponding `conhost.exe`. The accumulated `taskkill` instances repeatedly query `Win32_Process`, exhaust the WMI provider quota, and make the entire Windows UI sluggish or unable to launch new processes. This is related to openai/codex#17229 and openai/codex#21957, but the leaking processes in this case are `taskkill.exe` themselves rather than only `git.exe`/`conhost.exe` or leaked stdout. ## Environment * Codex Desktop: `26.715.4045.0` * OS: Windows 25H2 x64, build `26200.8875` * RAM: 32 GB * Installation: Microsoft Store/MSIX package `OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0` ## Observed behavior During normal local-agent use involving shell commands, cancellations, and command timeouts, process counts grew continuously. Peak measurements: * `taskkill.exe`: 457 processes * `conhost.exe`: 473 processes * total processes: 1,388 * total threads: over 14,000 * total handles: over 350,000 * WMI provider private memory: 720.5 MB All sampled `taskkill.exe` instances had the Codex Desktop main process (`ChatGPT.exe` inside the `OpenAI.Codex` package) as their parent. Most excess `conhost.exe` instances were children of those `taskkill.exe` processes. Windows Event Viewer recorded: * WMI event 5612: `PrivatePageCount` exceeded its 512 MB quota. * WMI event 5612: `ThreadCount` exceeded its 256-thread quota. * WMI Activity event 5858: repeated `Win32_Process` queries failed with `0x80041006` and `0x80041033`. * `taskkill.exe` crashed with exception `0xc0000005` (Application Error event 1000 / Windows Error Reporting event 1001). Killing the accumulated `taskkill.exe` processes immediately reduced the total process count from 1,388 to about 565, and WMI private memory fell from 720.5 MB to about 104 MB. However, while the original Codex process remained running, `taskkill.exe` counts grew again from 156 to 320 in 20 seconds. Fully restarting/reinstalling Codex cleared the bad state. With the same app version reinstalled, the stable baseline was: * `taskkill.exe`: 0 * `conhost.exe`: 12 * total processes: about 390 * WMI: 139 MB private memory / 54 threads Because the reinstalled version is identical, this appears to clear the accumulated state rather than fix the underlying bug. ## Relevant packaged-app implementation Inspection of the installed `app.asar` shows that the Windows process-tree cleanup path invokes approximately: ```js execFile(taskkill.exe, [\"/pid\", pid, \"/t\", \"/f\"], { windowsHide: true, }); ``` The call does not appear to set a timeout. Cleanup is deduplicated per execution object, but there is no apparent global concurrency limit, backoff, or circuit breaker across multiple local executions. If `taskkill.exe` hangs because process enumeration/WMI is unhealthy, later cleanups can start additional `taskkill.exe` instances indefinitely. ## Steps that may reproduce 1. Open Codex Desktop on Windows and a local repository. 2. Run multiple local shell operations, including operations that time out or are cancelled. 3. Observe `taskkill.exe` and `conhost.exe` in Task Manager or Process Explorer. 4. If WMI/process enumeration becomes slow, observe whether `taskkill.exe` instances remain alive and increase continuously. 5. Keep the app open and observe WMI event 5858 failures and growing process/thread/handle counts. The trigger is intermittent; the unbounded accumulation after the first stuck cleanup is the main defect. ## Expected behavior * A process-tree cleanup should complete or time out within a bounded period. * Codex should not run hundreds of concurrent `taskkill.exe` cleanup processes. * Repeated cleanup failures should activate backoff/circuit breaking and surface one actionable error to the user. * Failure of WMI/process enumeration should not cause a system-wide process storm. ## Suggested fixes 1. Add a timeout to the `taskkill.exe` invocation and forcibly terminate a stuck cleanup helper. 2. Add a process-wide single-flight or small concurrency limit for Windows tree cleanup. 3. Add exponential backoff/circuit breaking after repeated cleanup failures. 4. Prefer Windows Job Objects or direct Win32 process-tree termination instead of spawning `taskkill.exe` for every cleanup. 5. Log the target PID, duration, exit status, and number of concurrent cleanup operations.", "url": "https://github.com/openai/codex/issues/34260", "createdAt": "2026-07-20T03:58:11Z", "updatedAt": "2026-08-13T03:42:51Z", "timestamp": "2026-08-13T03:42:51Z", "metrics": { "reactions": 13, "comments": 34 }, "labels": [ "bug", "windows-os", "tool-calls", "app", "performance", "Papercuts 2026" ], "author": "RocStone", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/34260", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-9f29e8643674" }, { "tier": "triage-lead", "rankScore": 39, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:37458", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "# Codex extension fails to start: \"The extension couldn't load its resources\"", "text": "## Description The Codex panel fails to start after opening VSCode and shows: > Codex could not start. The extension couldn't load its resources. ## Environment - OS: Windows x64 - VSCode: 1.132.0 (commit `df53daabb18cd157bdb08c7f01c34df936cf12f4`) - Extension: `openai.chatgpt` 26.803.41515 (win32-x64) - Extension installed/updated: 2026-08-07 ## Steps to reproduce 1. Open VSCode. 2. Open the Codex sidebar or panel. 3. Wait about 30 seconds; the error \"Codex couldn't load its resources.\" appears. ## Console output (Developer Tools) Key error lines: ``` index.html?id=...&extensionId=openai.chatgpt... Loading the font 'data:font/woff2;base64,...' violates the following Content Security Policy directive: \"font-src 'self' https://*.vscode-cdn.net\". The action has been blocked. ... Codex couldn't load its resources. ``` ## Troubleshooting already tried - Developer: Reload Window - Fully quit and restart VSCode - Uninstall and reinstall the Codex extension - Cleared `%APPDATA%\\Code\\Service Worker\\CacheStorage` and `ScriptCache` - Tried to roll back the extension version, but \"Install Another Version...\" failed with \"Error while downloading VSIX: Canceled\" ## Additional analysis From the extension source, `initializeWebview` sets a 30-second startup timeout for the webview and requires a `ready` message within that window. If VSCode's CSP blocks the `data:font` resource, the frontend may fail to initialize and trigger this error. Please confirm compatibility between `26.803.41515` and VSCode `1.132.0`, and consider whether the webview's `data:font` should be served differently.", "url": "https://github.com/openai/codex/issues/37458", "createdAt": "2026-08-07T15:22:08Z", "updatedAt": "2026-08-13T12:47:08Z", "timestamp": "2026-08-13T12:47:08Z", "metrics": { "reactions": 11, "comments": 52 }, "labels": [ "bug", "windows-os", "extension" ], "author": "YeNai-ShaoXianChao", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/37458", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-15c879114cd7" }, { "tier": "triage-lead", "rankScore": 39, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:8745", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "LSP integration (auto-detect + auto-install) for Codex CLI", "text": "### What feature would you like to see? ## Summary Please add **built-in Language Server Protocol (LSP) support** to Codex CLI, including **auto-detection and auto-installation** of popular language servers. The goal is for Codex CLI to use LSP diagnostics and symbol intelligence to produce **more precise, language- and project-aware code edits** with minimal or zero manual setup. ## Motivation / Problem Codex CLI is often used on real repositories that are: - multi-language (frontend + backend + infra) - strongly typed / toolchain-driven (TypeScript, Go, Rust, C#, Java, etc.) - linted and configured per-project (eslint rules, tsconfig, deno.json, etc.) Without structured feedback, the model can produce changes that: - fail type-checking or compilation (wrong imports/types/symbols) - violate project conventions/tooling config - require repeated manual cycles of build/test/lint to discover issues LSP servers provide **semantic diagnostics + code intelligence**. If Codex CLI can optionally leverage LSP signals during the edit loop, it becomes significantly more reliable. ## Proposal Add an **LSP Manager** to Codex CLI with: 1) **Auto-detection** based on file extensions and project markers (package.json, deno.json, go.mod, etc.) 2) A **built-in server mapping** (language -> LSP server + install strategy + requirements) 3) **Auto-install** (opt-in by default, or prompted) for servers that can be installed automatically 4) **Lifecycle management** (start/stop, per-workspace, prefer stdio transport) 5) **Document sync** (didOpen/didChange/didSave) 6) Use LSP output as feedback for code edits: - publishDiagnostics (must) - document/workspace symbols, definition/references (high value) - optional: hover/signatureHelp ### CLI / UX suggestion - `codex --lsp=auto` (or `--lsp=on`), `codex --lsp=off` - `codex lsp status` (which servers detected, installed, running) - `codex lsp diagnostics [--file path]` (print diagnostics used by Codex) - Optional: `codex fix --with-lsp` (iterate until diagnostics improve / are clean) ## Built-in LSP server matrix (target scope) Codex CLI should ship with a curated built-in list like: | LSP Server | Extensions | Requirements / Install behavior | |---|---|---| | astro | .astro | Auto-installs for Astro projects | | bash | .sh, .bash, .zsh, .ksh | Auto-installs bash-language-server | | clangd | .c, .cpp, .cc, .cxx, .c++, .h, .hpp, .hh, .hxx, .h++ | Auto-installs for C/C++ projects | | csharp | .cs | .NET SDK installed | | clojure-lsp | .clj, .cljs, .cljc, .edn | clojure-lsp command available | | dart | .dart | dart command available | | deno | .ts, .tsx, .js, .jsx, .mjs | deno command available (auto-detect deno.json/deno.jsonc) | | elixir-ls | .ex, .exs | elixir command available | | eslint | .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts, .vue | eslint dependency in project | | fsharp | .fs, .fsi, .fsx, .fsscript | .NET SDK installed | | gleam | .gleam | gleam command available | | gopls | .go | go command available | | jdtls | .java | Java SDK (version 21+) installed | | kotlin-ls | .kt, .kts | Auto-installs for Kotlin projects | | lua-ls | .lua | Auto-installs for Lua projects | | nixd | .nix | nixd command available | | ocaml-lsp | .ml, .mli | ocamllsp command available | | oxlint | .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts, .vue, .astro, .svelte | oxlint dependency in project | | php intelephense | .php | Auto-installs for PHP projects | | prisma | .prisma | prisma command available | | pyright | .py, .pyi | pyright dependency installed | | ruby-lsp (rubocop) | .rb, .rake, .gemspec, .ru | ruby and gem commands available | | rust | .rs | rust-analyzer command available | | sourcekit-lsp | .swift, .objc, .objcpp | swift installed (xcode on macOS) | | svelte | .svelte | Auto-installs for Svelte projects | | terraform | .tf, .tfvars | Auto-installs from GitHub releases | | tinymist | .typ, .typc | Auto-installs from GitHub releases | | typescript | .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts | typescript dependency in project | | vue | .vue | Auto-installs for Vue projects | | yaml-ls | .yaml, .yml | Auto-installs Red Hat yaml-language-server | | zls | .zig, .zon | zig command available | This is the “built-in” experience requested: detection + install + run handled by Codex CLI without users wiring it manually. ## Installation model (recommended) - Install servers into a Codex-managed cache directory (per-user), pinned versions. - Prefer official distribution channels: - npm-based servers (typescript-language-server, bash-language-server, yaml-language-server, etc.) - GitHub releases for binaries (terraform-ls, tinymist, etc.) with checksums - Respect “project-provided” servers when present (eslint/ts in node_modules, pyright dependency, etc.) - Provide safe defaults and clear logs: - prompt before downloads, or allow `--yes` for non-interactive installs - allow `--lsp=off` to disable all LSP activity ## Acceptance criteria - `codex --lsp=auto` detects language(s) and starts appropriate server(s) or explains unmet requirements. - For supported auto-install servers, Codex CLI can install them and cache them. - Codex CLI can surface or internally use LSP diagnostics for edited files. - Optional “fix loop”: improve patches using diagnostics until stable/clean or max iterations reached. - Graceful fallback when a server is missing/unavailable, without breaking Codex CLI. ## Security / Privacy considerations - LSP processes run locally and only access the workspace. - Clear opt-in behavior for downloads and execution. - Ability to disable LSP entirely and to view which commands are being executed. ### Additional information ## Primary use cases - Multi-language repos (e.g., TS + Python + Terraform) - Large refactors where symbol navigation/definitions matter - Reducing trial-and-error cycles with build/lint/test ## Environment - OS: macOS (can also test on Linux if needed) - Common toolchains available depending on repo: Node/npm, Go, Rust, .NET, Java", "url": "https://github.com/openai/codex/issues/8745", "createdAt": "2026-01-05T16:56:36Z", "updatedAt": "2026-08-13T08:16:51Z", "timestamp": "2026-08-13T08:16:51Z", "metrics": { "reactions": 543, "comments": 61 }, "labels": [ "enhancement", "agent" ], "author": "danielsacosta", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/8745", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-f94a4787afa9" }, { "tier": "triage-lead", "rankScore": 38, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:28729", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Link a source control repo as the source for organization skills", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Currently the only way to manage org-level skills is uploading them individually through the Claude.ai admin console. This sorta works when you have a handful of skills, but even then you're manually re-uploading after every revision. Once you get to 20-30+ skills with multiple contributors, it becomes difficult to manage — there's no version history, no review process, and no easy way to roll back a bad change. The plugin marketplace system supports git repos, but it's user-configured rather than admin-controlled. The `extraKnownMarketplaces` managed setting that could help with this is currently broken (#16870), and there are open issues with marketplace auto-update (#26744) and the upload process itself (#16625, #27979). Org skill management feels like an incomplete feature — the foundation is there but it's missing the tooling to make it practical at scale. ### Proposed Solution Allow org admins to link a source control repository as the skill source for their organization. Any git remote would work — GitHub, GitLab, Bitbucket, Azure DevOps, self-hosted Gitea, etc. **Admin side:** - In org settings, connect a git repo URL (public or private) as the skill source - Pick a branch, tag, or commit to deploy from - Preview changes before syncing - Sync manually, or optionally auto-sync on push via webhook **User side:** - Org skills from the linked repo appear automatically — no per-user setup needed - Indicator when newer skills are available - One click or command to pull the latest **CI:** - Claude Code in CI picks up the same org skills automatically - Can pin to a specific commit for reproducibility ### Alternative Solutions _No response_ ### Priority Medium - Would be very helpful ### Feature Category Configuration and settings ### Use Case Example Our team maintains around 20 org skills for code review standards, security checks, and deployment workflows. Today someone edits a skill locally, uploads it through the admin console, and nobody reviews the change. If something breaks, we piece together what happened through Slack. With a linked repo, skill changes would go through the same merge request and review process as any other code. On merge, the org's skills update. If something's wrong, revert the commit. Standard development workflow applied to skills. ### Additional Context Related: #25771 — Programmatic skill deployment via CLI/API (complementary — covers the CI/CD push side, this covers the persistent source-of-truth side)", "url": "https://github.com/anthropics/claude-code/issues/28729", "createdAt": "2026-02-25T20:28:50Z", "updatedAt": "2026-08-13T15:52:02Z", "timestamp": "2026-08-13T15:52:02Z", "metrics": { "reactions": 139, "comments": 39 }, "labels": [ "enhancement", "area:skills" ], "author": "KyleNesium", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/28729", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-77ff17c495a5" }, { "tier": "triage-lead", "rankScore": 38, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:29006", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Enable Remote Control for Claude Code sessions in Claude Desktop App", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Feature Request The recently released Remote Control (/remote-control) feature only works from the Claude Code CLI(cursor in my case). When running Claude Code through the Claude Desktop app (Agent SDK / MCP integrations), there is no way to activate Remote Control or continue the session from a mobile device. Problem Users running Claude Code via the Desktop app have the same local environment access (filesystem, MCP servers, Supabase, browser tools, etc.) as CLI users, but no path to connect from their phone. The Desktop app sessions don't sync to claude.ai or the mobile app since they're local by design — which is exactly the gap Remote Control was built to solve. Expected Behavior Desktop app Claude Code sessions should support Remote Control the same way CLI sessions do — expose a session URL / QR code to connect from the Claude mobile app or claude.ai/code. Why It Matters Many users run Claude Code through Desktop app integrations rather than a raw terminal. Being locked out of Remote Control because of the entry point (Desktop app vs CLI) is an unnecessary limitation when the underlying session capabilities are the same. ### Proposed Solution Just enable it on claude desktop app.Its a fairly reasonable expectation that would have me move to the claude desktop app only ### Alternative Solutions _No response_ ### Priority High - Significant impact on productivity ### Feature Category CLI commands and flags ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/29006", "createdAt": "2026-02-26T13:44:46Z", "updatedAt": "2026-08-13T14:53:12Z", "timestamp": "2026-08-13T14:53:12Z", "metrics": { "reactions": 159, "comments": 37 }, "labels": [ "enhancement", "area:desktop" ], "author": "NickvZyl", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/29006", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-b63e993efede" }, { "tier": "triage-lead", "rankScore": 38, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:40495", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Cowork sessions ignore user hooks and managed settings — sandbox platform mismatch breaks all settings resolution", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Cowork (local-agent-mode) sessions silently ignore **all three settings sources**: user settings (`~/.claude/settings.json`), managed/MDM settings (`/Library/Application Support/ClaudeCode/managed-settings.json`), and environment variable overrides. This means user-defined hooks never fire, enterprise managed policies are not enforced, and env-based configuration (e.g. `CLAUDE_CODE_EFFORT_LEVEL`) has no effect. **This is distinct from #27398** (plugin hooks via `--setting-sources user`). That issue covered plugin-scoped hook discovery being excluded by the `--setting-sources` flag. This issue covers three additional, independent root causes that affect **all** settings — not just plugin hooks — and persist even if `--setting-sources` were fixed. #### Root Cause 1: User settings file doesn't exist in the sandbox The sandbox sets `CLAUDE_CONFIG_DIR=/sessions//mnt/.claude`. In cowork mode, the binary looks for `cowork_settings.json` (via the `WK5()` / `getSettingsFilename()` function that checks `isCowork()`). This file does not exist in the sandbox — only `.claude.json` is present. The user's actual `~/.claude/settings.json` on the macOS host is never mounted into the VM. **Verified from inside the sandbox:** ``` $ echo $CLAUDE_CONFIG_DIR /sessions/eloquent-upbeat-albattani/mnt/.claude $ ls $CLAUDE_CONFIG_DIR/settings.json No such file or directory $ ls $CLAUDE_CONFIG_DIR/cowork_settings.json No such file or directory ``` #### Root Cause 2: Managed settings path resolves to wrong location (platform mismatch) The managed settings directory is resolved by `process.platform`: ```javascript // Reconstructed from compiled binary function getManagedSettingsDir() { switch (getPlatform()) { case \"macos\": return \"/Library/Application Support/ClaudeCode\"; case \"windows\": return \"C:\\\\Program Files\\\\ClaudeCode\"; default: return \"/etc/claude-code\"; // Linux falls here } } ``` The cowork sandbox is a **Linux VM** (Ubuntu 22.04 aarch64), so `process.platform` is `linux`, and the binary looks for `/etc/claude-code/managed-settings.json`. This path does not exist in the sandbox. The macOS host path (`/Library/Application Support/ClaudeCode/`) is never consulted. Note: `CLAUDE_CODE_HOST_PLATFORM=darwin` is set as an env var, but the binary uses `process.platform` (which is `linux`), not this env var, for path resolution. **Verified from inside the sandbox:** ``` $ uname -s Linux $ ls /etc/claude-code/ No such file or directory $ ls /Library/ No such file or directory $ echo $CLAUDE_CODE_HOST_PLATFORM darwin ``` #### Root Cause 3: User environment variables are not forwarded into the sandbox The sandbox receives a curated set of env vars (`CLAUDE_CODE_IS_COWORK`, `CLAUDE_CONFIG_DIR`, OAuth tokens, proxy ports, etc.), but user-set environment variables like `CLAUDE_CODE_EFFORT_LEVEL` from the macOS host are not forwarded. ``` $ echo $CLAUDE_CODE_EFFORT_LEVEL (empty) ``` This means the documented workaround from #34428 (`CLAUDE_CODE_EFFORT_LEVEL=max` in settings.json `env` block) doesn't work for cowork — settings.json isn't loaded (Root Cause 1), and even if set in the host shell, the env var isn't forwarded (Root Cause 3). ### Impact | Settings Source | Interactive CLI | Headless (`-p`) | Cowork | Root Cause | |---|---|---|---|---| | `~/.claude/settings.json` hooks | Fire | Fire | **Silent no-op** | Config dir has no settings file | | Managed settings (MDM) | Loaded | Loaded | **Silent no-op** | Platform mismatch → wrong path | | `CLAUDE_CODE_EFFORT_LEVEL` env | Works | Works | **Ignored** | Env not forwarded to sandbox | | `.claude.json` (OAuth/flags) | Loaded | Loaded | Loaded | ✅ Mounted via bindfs | **Enterprise concern:** Managed settings are designed for policy enforcement via MDM profiles. Having them silently ignored in cowork means enterprise admins cannot enforce hooks, permission rules, or other policies in cowork sessions — a compliance gap. ### What Should Happen? 1. User hooks from `~/.claude/settings.json` should be mounted/copied into the sandbox as `cowork_settings.json` (or the binary should read from a host-provided path) 2. Managed settings from the macOS host should be bind-mounted into the sandbox at `/etc/claude-code/managed-settings.json` (the Linux-expected path), since the binary already knows how to load from there 3. User env vars relevant to Claude Code (at minimum `CLAUDE_CODE_EFFORT_LEVEL`) should be forwarded into the sandbox ### Error Messages/Logs No errors — all three failures are **silent**. Settings resolution finds no file and returns empty/default. This is part of the problem: there's zero indication that settings are being ignored. ### Steps to Reproduce 1. Add hooks to `~/.claude/settings.json` on the macOS host (e.g., a `PostToolUse` hook that writes to a log file) 2. Confirm the hooks fire in an interactive `claude` CLI session 3. Start a Cowork session in Claude Desktop 4. Trigger the same hook event (e.g., use a tool) 5. Observe that hooks never fire — no log file is written, no hook output appears 6. Optionally verify from inside the sandbox (if you can get shell access) that `$CLAUDE_CONFIG_DIR/cowork_settings.json` and `/etc/claude-code/managed-settings.json` don't exist ### Claude Model claude-opus-4-6 ### Is this a regression? No, this never worked ### Last Working Version _No response_ ### Claude Code Version Cowork VM binary at `/usr/local/bin/claude` (version embedded in Bun-compiled binary, matches latest Claude Desktop release) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Other ### Additional Information **Related issues:** - #27398 — Cowork plugin hooks not firing due to `--setting-sources user` (closed as duplicate, different root cause from this issue) - #32364 — OTel config not available in sandboxed environments (same underlying problem: settings.json inaccessible in sandbox) - #34428 — Effort level not persisted (workaround via settings.json `env` block doesn't work in cowork) **Key environment variables in the cowork sandbox:** ``` CLAUDECODE=1 CLAUDE_CODE_IS_COWORK=1 CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CONFIG_DIR=/sessions//mnt/.claude HOME=/sessions/ CLAUDE_CODE_HOST_PLATFORM=darwin SANDBOX_RUNTIME=1 ``` **Sandbox architecture:** Linux VM (Ubuntu 22.04 aarch64) using bubblewrap (`bwrap`) for process isolation. Host directories are selectively bind-mounted via bindfs FUSE mounts with controlled permissions. The `.claude/` directory is mounted read-write but only contains `.claude.json` — no `settings.json` or `cowork_settings.json`.", "url": "https://github.com/anthropics/claude-code/issues/40495", "createdAt": "2026-03-29T05:58:07Z", "updatedAt": "2026-08-13T17:14:21Z", "timestamp": "2026-08-13T17:14:21Z", "metrics": { "reactions": 19, "comments": 21 }, "labels": [ "bug", "has repro", "platform:macos", "area:hooks", "area:cowork" ], "author": "gmnbs", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/40495", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-4dc1ba1a2dda" }, { "tier": "triage-lead", "rankScore": 38, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:30440", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex uses bundled pnpm instead of host toolchain", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.623.42026 ### What subscription do you have? Pro ### What platform is your computer? Darwin 24.6.0 arm64 arm ### What issue are you seeing? Codex is consistently failing to run my build script because that script invokes `pnpm install`. As per its own diagnosis: - My local projects uses PNPM v10 - Codex comes bundled with PNPM v11 in `~/.cache/codex-runtimes/codex-primary-runtime/dependencies/bin/pnpm` - When running the build script, Codex uses the bundled one, leading to failure to resolve dependencies, whereas the build script is run fine in any local terminal ### What steps can reproduce the bug? 1. Create a pnpm v10 project with dependencies in package.json 2. Run `pnpm install` in **terminal** to install the dependencies 3. Create a js script ```javascript import { spawn } from \"node:child_process\"; const child = spawn(\"pnpm\", [\"install\"], { cwd: process.cwd(), stdio: [\"ignore\", \"pipe\", \"pipe\"], }); child.on(\"close\", (code) => { process.exit(code ?? 1); }); ``` 4. Ask Codex (with pnpm v11 bundled) to run `node script.mjs` inside project dir ### What is the expected behavior? Codex should use my local pnpm binary, and ask for permission elevation when needed. In fact, using this to run the build script is fine: `PATH=\"path-to-my-local-nodejs/bin:$PATH\" CI=true node script.mjs` ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/30440", "createdAt": "2026-06-28T10:58:46Z", "updatedAt": "2026-08-13T06:15:23Z", "timestamp": "2026-08-13T06:15:23Z", "metrics": { "reactions": 28, "comments": 21 }, "labels": [ "bug", "sandbox", "app" ], "author": "kkaatii", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/30440", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-01fdef03c423" }, { "tier": "triage-lead", "rankScore": 37, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:28791", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Sync conversation history between CLI and Claude Code desktop app", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Currently, conversations I have in the Claude Code CLI (terminal) don't show up in the Claude Code desktop app, and vice versa. They're completely separate with no shared history. It would be great if both interfaces could access the same conversation history. I often start working on a project in the terminal and later want to continue or review that same conversation from the desktop app. Right now there's no way to do that. Even a read-only view of CLI sessions in the desktop app would be a huge improvement. Being able to resume them from either interface would be even better. ### Proposed Solution - Sync conversation history between the CLI and the desktop app so sessions are accessible from both interfaces - Allow resuming CLI sessions from the desktop app and vice versa - Show desktop notifications when Claude needs input or wants to ask a question ### Alternative Solutions _No response_ ### Priority Critical - Blocking my work ### Feature Category CLI commands and flags ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/28791", "createdAt": "2026-02-26T00:40:47Z", "updatedAt": "2026-08-13T08:23:14Z", "timestamp": "2026-08-13T08:23:14Z", "metrics": { "reactions": 146, "comments": 33 }, "labels": [ "enhancement", "area:cli", "area:desktop" ], "author": "moazam1", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/28791", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-cef791d25728" }, { "tier": "triage-lead", "rankScore": 37, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:25178", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Computer Use screenshot fails on Windows 10 22H2 when SetIsBorderRequired is called", "text": "### Summary On Windows Codex Desktop, Computer Use can list apps/windows, activate windows, read accessibility text, and send keyboard input, but any `get_window_state` call that requests a screenshot fails before capture with: ```text SetIsBorderRequired failed: 不支持此接口 (0x80004002) ``` The same target window works when requesting accessibility text only (`include_screenshot: false, include_text: true`). This looks like the Windows capture helper unconditionally calls `GraphicsCaptureSession.IsBorderRequired` / `SetIsBorderRequired` on a Windows build that does not support that property. ### Environment Sanitized user machine details: - Platform: Windows Codex Desktop - Codex app package observed: `OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0` - Computer Use plugin observed: `computer-use/26.527.31326` - OS: Windows 10 Pro 22H2 - OS build: `10.0.19045` - GPU: NVIDIA GeForce GTX 1060 3GB - DirectX: 12 - Driver model: WDDM 2.7 - Remote/virtual display drivers also present: ToDesk Virtual Display Adapter, Oray Display Mirror Driver ### Reproduction From the Computer Use client in Codex Desktop on this Windows 10 machine: 1. Bootstrap Computer Use and call `sky.list_apps()`. 2. Open or select a simple window such as Notepad. 3. Activate the window. 4. Call any screenshot-including state request, for example: ```js await sky.get_window_state({ window: targetWindow }); // or await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: false }); // or await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: true }); ``` 5. The call fails with: ```text SetIsBorderRequired failed: 不支持此接口 (0x80004002) ``` 6. Calling text-only succeeds: ```js await sky.get_window_state({ window: targetWindow, include_screenshot: false, include_text: true }); ``` Observed text-only result against Notepad included a focused editor element and accessibility tree, proving that the helper, native pipe, app enumeration, activation, and accessibility path are otherwise working. ### Observed Batch Test Results ```json { \"notepad_default_screenshot\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\", \"notepad_explicit_screenshot\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\", \"notepad_text_only\": \"ok\", \"notepad_both\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\", \"explorer_screenshot\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\" } ``` ### Suspected Cause Microsoft documents `GraphicsCaptureSession.IsBorderRequired` as introduced in Windows 10 version 2104 / build `10.0.20348.0`, API contract v12: https://learn.microsoft.com/en-us/uwp/api/windows.graphics.capture.graphicscapturesession.isborderrequired This repro machine is Windows 10 build `19045`, so `SetIsBorderRequired` appears to hit `E_NOINTERFACE` (`0x80004002`, no such interface supported). The capture helper seems to abort instead of continuing without border toggling. ### Expected Behavior On Windows builds where border toggling is unsupported, Computer Use should still capture screenshots if the underlying Windows Graphics Capture path is otherwise available. Suggested behavior: - Gate the border call with `ApiInformation.IsPropertyPresent(\"Windows.Graphics.Capture.GraphicsCaptureSession\", \"IsBorderRequired\")`, or an equivalent OS/API contract check. - If unsupported, skip `SetIsBorderRequired` and allow the default capture border behavior. - Alternatively, fail with a clear compatibility error such as: `Computer Use screenshots require Windows build 20348+ because border toggling is currently unconditional`. ### Impact This leaves Computer Use partially functional on Windows 10 22H2: - Working: app/window enumeration, activation, accessibility text, keyboard input. - Broken: screenshot-based UI inspection and accurate coordinate-based visual interaction. For users on Windows 10 build 19045, this means Computer Use cannot reliably operate visual apps even though non-visual operations work.", "url": "https://github.com/openai/codex/issues/25178", "createdAt": "2026-05-30T00:16:32Z", "updatedAt": "2026-08-12T22:45:03Z", "timestamp": "2026-08-12T22:45:03Z", "metrics": { "reactions": 13, "comments": 25 }, "labels": [ "bug", "windows-os", "app", "computer-use" ], "author": "Define1165250535", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/25178", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-2466c535a9d7" }, { "tier": "triage-lead", "rankScore": 37, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:32177", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App: text-log attachment can trigger “Request blocked” and poison subsequent turns", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.707.31428 ### What subscription do you have? ChatGPT Team ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? In Codex App, attaching a plain-text application log to an established thread can cause the turn to fail after approximately 3–5 seconds with only: ```text Request blocked. ``` The failure is persistent within that thread. Sending a subsequent short message without any attachment also fails with the same generic error because the rejected attachment turn remains in the conversation history. The affected turns complete without an assistant response. Local thread events show a completed task with no final assistant message. The desktop logs do not show an authentication, rate-limit, or HTTP 401/403/429 failure. This reproduced with multiple different plain-text logs. The logs contained ordinary service diagnostics, model-loading messages, token counts, and request metadata. They did not contain credentials. A control request in a new, short thread succeeds with the same account and model. ### What steps can reproduce the bug? 1. Open Codex App and use an established local-project thread with substantial completed history. 2. Confirm that a normal turn still succeeds. 3. Attach a plain-text service log. Reproduced attachment sizes ranged from approximately 42 KB / 425 lines to 115 KB / 1,094 lines. 4. Ask Codex to inspect or summarize the log. 5. Observe that the turn ends after approximately 3–5 seconds with `Request blocked.` and no assistant message. 6. Send a short follow-up without an attachment. 7. Observe that the follow-up is also blocked because the rejected attachment turn remains in the thread history. 8. Create a new thread in the same project and send a short prompt without carrying over the attachment. Observe that it succeeds. Relevant diagnostics: - Model: `gpt-5.6-sol`, medium reasoning. - Last successful turn before the attachment used 160,985 input tokens with a reported 353,400-token context window. - Account usage was below 10%; no rate-limit-reached state was reported. - Directly resuming the affected thread through the bundled CLI reproduces `ERROR: Request blocked.`, so this is not only a stale renderer banner. - Session identifiers are intentionally omitted for privacy, but can be supplied privately if maintainers provide a secure channel. ### What is the expected behavior? Codex App should do one of the following: 1. Accept the attachment when the combined request fits the supported context and request limits. 2. Proactively compact, truncate, or summarize the attachment/history before sending. 3. Reject the attachment before creating the turn and display a specific actionable error, such as an attachment-size or request-size limit. A failed attachment turn must not poison the thread. A subsequent message without the attachment should work, or the UI should provide a clear way to remove/rollback the rejected turn. ### Additional information - Reproduced after a full app restart. - Clearing GUI caches and refreshing authentication did not change the behavior. - Authentication and ordinary requests remained functional. - No screenshots or raw logs are attached because they may contain private workspace information. - No absolute local paths are included in this report.", "url": "https://github.com/openai/codex/issues/32177", "createdAt": "2026-07-10T14:25:59Z", "updatedAt": "2026-08-13T14:55:39Z", "timestamp": "2026-08-13T14:55:39Z", "metrics": { "reactions": 19, "comments": 17 }, "labels": [ "bug", "context", "app", "session" ], "author": "66Ton99", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/32177", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-0955223f043f" }, { "tier": "triage-lead", "rankScore": 37, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:33875", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex Desktop Version: 26.715.2305.0 ### What subscription do you have? pro 20x ### What platform is your computer? windows ### What issue are you seeing? High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 Environment OS: Windows 10 Pro x64 CPU: Intel Core i5-10400F RAM: 16 GB GPU: NVIDIA GTX 1650 Codex Desktop Version: 26.715.2305.0 Installation: Microsoft Store Summary Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project. The CPU reaches 90–100% due to the combination of: ChatGPT / Codex processes Windows Defender (Antimalware Service Executable) WMI Provider Host (WmiPrvSE.exe) This significantly increases CPU temperature and system load. Expected Behavior Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension). Actual Behavior Immediately after launching Codex Desktop: CPU usage jumps to 90–100%. Windows Defender starts consuming 20–40% CPU. WMI Provider Host also starts consuming 10–20% CPU. CPU temperature increases accordingly. This happens even while sitting on the Home screen without opening any workspace. Troubleshooting Performed I tested all of the following: ✅ Replaced CPU thermal paste. ✅ Verified CPU cooler installation. ✅ Tested CPU temperatures (hardware is working normally). ✅ Added Windows Defender exclusions for: Project folder C:\\Users\\\\AppData\\Local\\OpenAI ...\\Codex\\runtimes ✅ Restarted Windows. ✅ Disabled Windows Defender Real-time Protection. ✅ Tested without opening any project. ✅ Tested after removing NVIDIA RTX Voice. ✅ Checked WMI logs. ✅ Rebuilt Windows Performance Counters. ✅ Verified CPU is normal outside Codex. None of these resolved the issue. Important Observation When Real-time Protection is disabled: Windows Defender CPU usage disappears. Codex CPU usage increases instead. This suggests Defender is scanning Codex activity rather than being the original source. Comparison with VS Code Using the Codex extension inside VS Code: CPU usage remains around 40–70% No abnormal Defender behavior. Much lower overall system load. Only Codex Desktop reproduces this issue. WMI Activity Windows Event Viewer shows continuous WMI queries such as: Win32_Processor Win32_OperatingSystem Win32_PerfFormattedData_PerfProc_Process WMI Provider Host becomes active immediately after launching Codex Desktop. Additional Notes The issue occurs: without opening any project after reboot with Defender exclusions configured even on the Home screen This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active. Request Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender? The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage. ### What steps can reproduce the bug? High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 Environment OS: Windows 10 Pro x64 CPU: Intel Core i5-10400F RAM: 16 GB GPU: NVIDIA GTX 1650 Codex Desktop Version: 26.715.2305.0 Installation: Microsoft Store Summary Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project. The CPU reaches 90–100% due to the combination of: ChatGPT / Codex processes Windows Defender (Antimalware Service Executable) WMI Provider Host (WmiPrvSE.exe) This significantly increases CPU temperature and system load. Expected Behavior Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension). Actual Behavior Immediately after launching Codex Desktop: CPU usage jumps to 90–100%. Windows Defender starts consuming 20–40% CPU. WMI Provider Host also starts consuming 10–20% CPU. CPU temperature increases accordingly. This happens even while sitting on the Home screen without opening any workspace. Troubleshooting Performed I tested all of the following: ✅ Replaced CPU thermal paste. ✅ Verified CPU cooler installation. ✅ Tested CPU temperatures (hardware is working normally). ✅ Added Windows Defender exclusions for: Project folder C:\\Users\\\\AppData\\Local\\OpenAI ...\\Codex\\runtimes ✅ Restarted Windows. ✅ Disabled Windows Defender Real-time Protection. ✅ Tested without opening any project. ✅ Tested after removing NVIDIA RTX Voice. ✅ Checked WMI logs. ✅ Rebuilt Windows Performance Counters. ✅ Verified CPU is normal outside Codex. None of these resolved the issue. Important Observation When Real-time Protection is disabled: Windows Defender CPU usage disappears. Codex CPU usage increases instead. This suggests Defender is scanning Codex activity rather than being the original source. Comparison with VS Code Using the Codex extension inside VS Code: CPU usage remains around 40–70% No abnormal Defender behavior. Much lower overall system load. Only Codex Desktop reproduces this issue. WMI Activity Windows Event Viewer shows continuous WMI queries such as: Win32_Processor Win32_OperatingSystem Win32_PerfFormattedData_PerfProc_Process WMI Provider Host becomes active immediately after launching Codex Desktop. Additional Notes The issue occurs: without opening any project after reboot with Defender exclusions configured even on the Home screen This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active. Request Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender? The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage. ### What is the expected behavior? _No response_ ### Additional information High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 Environment OS: Windows 10 Pro x64 CPU: Intel Core i5-10400F RAM: 16 GB GPU: NVIDIA GTX 1650 Codex Desktop Version: 26.715.2305.0 Installation: Microsoft Store Summary Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project. The CPU reaches 90–100% due to the combination of: ChatGPT / Codex processes Windows Defender (Antimalware Service Executable) WMI Provider Host (WmiPrvSE.exe) This significantly increases CPU temperature and system load. Expected Behavior Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension). Actual Behavior Immediately after launching Codex Desktop: CPU usage jumps to 90–100%. Windows Defender starts consuming 20–40% CPU. WMI Provider Host also starts consuming 10–20% CPU. CPU temperature increases accordingly. This happens even while sitting on the Home screen without opening any workspace. Troubleshooting Performed I tested all of the following: ✅ Replaced CPU thermal paste. ✅ Verified CPU cooler installation. ✅ Tested CPU temperatures (hardware is working normally). ✅ Added Windows Defender exclusions for: Project folder C:\\Users\\\\AppData\\Local\\OpenAI ...\\Codex\\runtimes ✅ Restarted Windows. ✅ Disabled Windows Defender Real-time Protection. ✅ Tested without opening any project. ✅ Tested after removing NVIDIA RTX Voice. ✅ Checked WMI logs. ✅ Rebuilt Windows Performance Counters. ✅ Verified CPU is normal outside Codex. None of these resolved the issue. Important Observation When Real-time Protection is disabled: Windows Defender CPU usage disappears. Codex CPU usage increases instead. This suggests Defender is scanning Codex activity rather than being the original source. Comparison with VS Code Using the Codex extension inside VS Code: CPU usage remains around 40–70% No abnormal Defender behavior. Much lower overall system load. Only Codex Desktop reproduces this issue. WMI Activity Windows Event Viewer shows continuous WMI queries such as: Win32_Processor Win32_OperatingSystem Win32_PerfFormattedData_PerfProc_Process WMI Provider Host becomes active immediately after launching Codex Desktop. Additional Notes The issue occurs: without opening any project after reboot with Defender exclusions configured even on the Home screen This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active. Request Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender? The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage.", "url": "https://github.com/openai/codex/issues/33875", "createdAt": "2026-07-17T17:22:32Z", "updatedAt": "2026-08-13T10:48:48Z", "timestamp": "2026-08-13T10:48:48Z", "metrics": { "reactions": 19, "comments": 17 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "ramisasa9080-blip", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/33875", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-8b1011e7b746" }, { "tier": "triage-lead", "rankScore": 36, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:24172", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "CRITICAL: Conversations disappear when closing VSCode or navigating away", "text": "## Description Conversations are completely disappearing and becoming unrecoverable when: - Closing and reopening VSCode - Navigating to the chat summary page and returning to a conversation - Switching between conversations The chat history is lost with no way to recover it. This makes it impossible to maintain long-running development sessions. ## Reproduction Steps 1. Start a conversation in Claude Code 2. Work for a while (multiple exchanges) 3. Close VSCode or navigate to chat summary page 4. Reopen VSCode or return to the conversation 5. **Expected**: Conversation history is preserved 6. **Actual**: Conversation is gone, completely vanished ## Impact - **Severity**: CRITICAL - Work cannot be persisted across sessions - **Blocker**: Prevents any meaningful development work - **Frequency**: 100% reproducible - happens every time ## Environment - OS: Windows (win32) - Date: 2026-02-08 - Branch: hdfc-skr-snapshot (finance_app) ## Current Workaround Users are forced to manually create git backups of entire conversation transcripts after each session, which is not a sustainable solution. ## Expected Behavior Claude Code conversations should persist automatically and be fully recoverable when: - Reopening VSCode - Returning from chat summary - Switching between active conversations This is a core feature that should \"just work\".", "url": "https://github.com/anthropics/claude-code/issues/24172", "createdAt": "2026-02-08T13:12:15Z", "updatedAt": "2026-08-13T08:25:40Z", "timestamp": "2026-08-13T08:25:40Z", "metrics": { "reactions": 25, "comments": 13 }, "labels": [ "bug", "has repro", "platform:windows", "area:core", "high-priority" ], "author": "krx5", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/24172", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-b1dfcad4e5b6" }, { "tier": "triage-lead", "rankScore": 36, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:62476", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code silently deletes conversation transcripts after 30 days by default", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? cleanupPeriodDays defaults to 30, causing Claude Code to silently delete ~/.claude/projects//.jsonl files older than 30 days on startup. There is no first-run disclosure, no warning before deletion, and the setting is not surfaced in /config. I lost months of conversation history before realizing this was happening. **Repro:** Use Claude Code for >30 days without setting cleanupPeriodDays. Old transcripts disappear. **Evidence on my machine:** ~/.claude/history.jsonl shows 14 sessions / 1,315 prompts for one project from March–April. Only the current session's .jsonl survives in ~/.claude/projects/. The cutoff matches the 30-day default exactly. My settings.json does not override the default. **Impact:** The code and git history remain, but the reasoning trail — design discussions, debugging context, analysis — is gone. For research work that context is the artifact. ### What Should Happen? **Requested:** 1. Change the default to non-destructive (disabled, or very long retention). 2. Disclose at first run; require opt-in for auto-deletion. 3. Soft-delete to a trash folder instead of unlink(). 4. Surface the setting in /config. Workaround for others: add \"cleanupPeriodDays\": 3650 to ~/.claude/settings.json immediately. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Use Claude Code for >30 days without setting cleanupPeriodDays. Old transcripts disappear. ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.150 ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell Other ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/62476", "createdAt": "2026-05-26T12:21:09Z", "updatedAt": "2026-08-13T12:20:53Z", "timestamp": "2026-08-13T12:20:53Z", "metrics": { "reactions": 19, "comments": 13 }, "labels": [ "bug" ], "author": "joelhochstetter", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/62476", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-8aa6996b5f9a" }, { "tier": "triage-lead", "rankScore": 36, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:71539", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Mouse click to refocus terminal triggers permission prompt unintentionally", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When a permission prompt is displayed (Yes / Yes all / No) in the new fullscreen TUI mode, clicking with the mouse to refocus the terminal window inadvertently triggers one of the choices. The scenario: another window is partially overlapping the terminal. The terminal is still visible on the side or edge. Clicking the visible part of the terminal to bring it back to focus lands on (or near) one of the permission options and triggers it — without the user seeing or intending the selection. The user's intent is only to restore focus, not to make a permission choice. This can silently grant or deny a tool use the user never consciously confirmed. Expected: the first click on an unfocused terminal should only restore focus, not trigger any interactive element inside the TUI. Suggested fix: ignore mouse input on the first click that restores focus to the terminal window, or require keyboard confirmation for permission prompts. Related issue (similar but distinct): #70178 — choices become unresponsive after refocus (macOS). This bug is the opposite: the click triggers a choice unintentionally on refocus (Linux, Warp terminal). ### What Should Happen? The first click on an unfocused terminal window should only restore focus, not trigger any interactive element inside the TUI. ### Error Messages/Logs ```shell No errors ``` ### Steps to Reproduce 1. Open Claude Code in fullscreen TUI mode. 2. Wait for a permission prompt to appear (Yes / Yes all / No). 3. Switch to another window so it partially overlaps the terminal. 4. The terminal (and the prompt) is still partially visible on the side or edge. 5. Click on the visible part of the terminal to bring it back to focus. 6. Observe that the click inadvertently triggers one of the permission options. ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.191 (Claude Code) ### Platform Anthropic API ### Operating System Other Linux ### Terminal/Shell Warp ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/71539", "createdAt": "2026-06-26T07:32:23Z", "updatedAt": "2026-08-13T15:56:58Z", "timestamp": "2026-08-13T15:56:58Z", "metrics": { "reactions": 23, "comments": 12 }, "labels": [ "bug", "platform:linux", "area:tui", "area:permissions" ], "author": "quenti77", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/71539", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-deb7ea3bd043" }, { "tier": "triage-lead", "rankScore": 36, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:16127", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "yeet skill is over opinionated", "text": "### What issue are you seeing? I was surprised when this skill triggered and added a codex/ to a branch name and a [codex] tag to the PR title. These should be opt-in. I was also annoyed that the skill triggered and used git commands on a repo that I manage with jj. ### What steps can reproduce the bug? \"PR this\" ### What is the expected behavior? Respect existing conventions ### Additional information 019d3603-1aac-7d51-a36a-3676d75469f7", "url": "https://github.com/openai/codex/issues/16127", "createdAt": "2026-03-28T20:42:17Z", "updatedAt": "2026-08-12T14:36:54Z", "timestamp": "2026-08-12T14:36:54Z", "metrics": { "reactions": 36, "comments": 15 }, "labels": [ "bug", "skills" ], "author": "joshka", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/openai/codex/issues/16127", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-dc7dd1eecc42" }, { "tier": "triage-lead", "rankScore": 36, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:34700", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App 26.715.9868.0 / CLI 0.145.0: spawn_agent rejects gpt-5.6-luna with multi_agent_v2 enabled", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.9868.0 (Windows package version) ### What subscription do you have? ChatGPT account; exact subscription tier is not displayed in this session. ### What platform is your computer? Microsoft Windows 11 Pro, NT 10.0.26200.0, x64 (build 26200) ### What issue are you seeing? The Codex desktop app is configured to use the standalone Codex CLI 0.145.0 through `CODEX_CLI_PATH`. The desktop log confirms that it spawned the external executable, and `codex --version` returns `codex-cli 0.145.0`. Both multi-agent flags are enabled: ```text multi_agent stable true multi_agent_v2 stable true ``` After fully restarting the desktop app, an explicit native subagent request with Luna and xhigh reasoning is rejected: ```json { \"fork_turns\": \"none\", \"model\": \"gpt-5.6-luna\", \"reasoning_effort\": \"xhigh\", \"task_name\": \"teste_luna_xhigh_v2\" } ``` Actual error: ```text Unknown model `gpt-5.6-luna` for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra ``` No child agent is created. The same result was reproduced after enabling MultiAgent V2 and restarting the app. ### What steps can reproduce the bug? 1. Install the official Windows x64 Codex CLI release 0.145.0. 2. Point the Codex desktop app to it using `CODEX_CLI_PATH=%LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin\\codex.exe`. 3. Verify `codex --version` returns `codex-cli 0.145.0`. 4. Run `codex features enable multi_agent_v2` and verify both `multi_agent` and `multi_agent_v2` are true. 5. Fully quit and reopen the Codex desktop app. 6. In a desktop task, call the native `spawn_agent` tool with `fork_turns: \"none\"`, `model: \"gpt-5.6-luna\"`, and `reasoning_effort: \"xhigh\"`. 7. Observe the unknown-model error stating that only `gpt-5.6-sol` and `gpt-5.6-terra` are available. ### What is the expected behavior? If Luna is intended to be available for configurable MultiAgent V2 children on this account/backend, `spawn_agent` should accept `gpt-5.6-luna` with `xhigh` reasoning and create the child agent. If Luna is intentionally unavailable because of an account, rollout, backend, or entitlement restriction, the app should expose that limitation clearly and document how users can determine or obtain the required availability. Currently the local feature is stable and enabled, but the requested model remains impossible to select. ### Additional information The 0.145.0 release notes describe configurable sub-agent models/reasoning in MultiAgent V2 and mention GPT-5.6 Terra and Luna variants, which led to the expectation that Luna could be selected when using the new release. This appears distinct from #20077 (full-history inheritance/model override behavior) and #26753 (encrypted tool schema request failure): this report reaches the `spawn_agent` tool and is rejected specifically because Luna is absent from the active model catalog. The issue was reproduced multiple times. No files were modified by the failed subagent calls, and no child agent was created.", "url": "https://github.com/openai/codex/issues/34700", "createdAt": "2026-07-22T08:08:41Z", "updatedAt": "2026-08-13T10:49:22Z", "timestamp": "2026-08-13T10:49:22Z", "metrics": { "reactions": 36, "comments": 14 }, "labels": [ "bug", "windows-os", "app", "subagent" ], "author": "enzopresbiteris-rgb", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/34700", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-4e00cd42929b" }, { "tier": "triage-lead", "rankScore": 35, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:13498", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Installation failed Failed to fetch version from stable: AxiosError: timeout of 30000ms exceeded", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The native installer fails with timeout errors on Ubuntu 22.04, despite curl successfully reaching all required endpoints. The installer times out at two different stages: 1. Initial version fetch - 30-second timeout fetching from https://storage.googleapis.com/.../stable 2. Binary download - 10-second timeout downloading from https://downloads.claude.ai/claude-code-releases/2.0.61/linux-x64/claude Both endpoints respond successfully to curl commands with 200 OK responses. The same installer works successfully on Ubuntu 24.04. ### What Should Happen? Installer should successfully download and install Claude Code, as it does on Ubuntu 24.04. ### Error Messages/Logs ```shell Key error from logs: 2025-12-09T19:02:39.044Z [ERROR] Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/stable: timeout of 30000ms exceeded 2025-12-09T19:02:39.045Z [ERROR] Install command failed: Error: Failed to fetch version from stable: AxiosError: timeout of 30000ms exceeded Network connectivity verified - all succeed with 200 OK: curl -I https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/stable curl -I https://downloads.claude.ai/claude-code-releases/2.0.61/manifest.json curl -I https://downloads.claude.ai/claude-code-releases/2.0.61/linux-x64/claude ``` ### Steps to Reproduce 1. On Ubuntu 22.04, run: curl -fsSL https://claude.ai/install.sh | bash 2. Installer times out fetching version from stable channel 3. Retry with specific version: curl -fsSL https://claude.ai/install.sh | bash -s 2.0.61 4. Installer times out downloading the binary (~100MB file) ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.0.61 ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell Other ### Additional Information OS: Ubuntu 22.04 LTS Installation method: Native installer (curl -fsSL https://claude.ai/install.sh | bash) Claude Code version: Attempting to install 2.0.61 (stable) Works on: Ubuntu 24.04 with same installer", "url": "https://github.com/anthropics/claude-code/issues/13498", "createdAt": "2025-12-09T19:31:00Z", "updatedAt": "2026-08-13T03:25:08Z", "timestamp": "2026-08-13T03:25:08Z", "metrics": { "reactions": 14, "comments": 13 }, "labels": [ "bug", "has repro", "platform:linux", "area:packaging" ], "author": "eblack-leaf", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/13498", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-390e800f2e5b" }, { "tier": "triage-lead", "rankScore": 35, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:16128", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] AWS Bedrock authentication support for Chrome extension", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Our organization uses AWS Bedrock for Claude access. The CLI supports this via CLAUDE_CODE_USE_BEDROCK=1, but the Chrome extension only supports Claude.ai account login. Users with Bedrock-only access cannot use the extension at all, creating an inconsistency where CLI works but extension doesn't. ### Proposed Solution Add Bedrock authentication to the Chrome extension, matching the CLI implementation. Flow: 1. Extension uses native messaging host to read AWS credentials (from ~/.aws/credentials or environment) 2. User enables Bedrock mode in settings and specifies region/profile 3. Extension connects via AWS Bedrock 4. Functions identically to standard version with different auth backend **Note:** Would require native messaging component since Chrome extensions can't directly access filesystem - similar to how extensions like 1Password work. **Important:** Must honor AWS Bedrock's data privacy guarantees - no data should leak to Anthropic's services. Organizations choose Bedrock specifically for data isolation. ### Alternative Solutions Current workaround: CLI only - extension cannot be used. ### Priority Medium - Would be very helpful ### Feature Category Other ### Use Case Example _No response_ ### Additional Context Additional Context: - CLI has full Bedrock support via environment variables - Enterprises use Bedrock for centralized access with corporate security", "url": "https://github.com/anthropics/claude-code/issues/16128", "createdAt": "2026-01-03T05:46:31Z", "updatedAt": "2026-08-13T13:30:27Z", "timestamp": "2026-08-13T13:30:27Z", "metrics": { "reactions": 113, "comments": 27 }, "labels": [ "enhancement", "api:bedrock", "area:auth", "area:ide" ], "author": "joaopixar", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/16128", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-bc825658eae0" }, { "tier": "triage-lead", "rankScore": 35, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:36024", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Support multiple Gmail accounts in MCP integration", "text": "## Feature request The Gmail MCP integration currently supports only one connected account at a time. Many users have multiple Gmail/Google Workspace accounts (personal + work) and would benefit from being able to connect more than one simultaneously. **Current behavior:** Only one Gmail account can be connected via MCP. Connecting a second requires disconnecting the first. **Desired behavior:** Ability to connect multiple Gmail accounts, with tools that can target a specific account (e.g., by email address). **Workaround:** Using the Gmail API via custom CLI scripts for additional accounts, but this loses the native structured access that MCP provides.", "url": "https://github.com/anthropics/claude-code/issues/36024", "createdAt": "2026-03-19T02:23:22Z", "updatedAt": "2026-08-13T13:03:23Z", "timestamp": "2026-08-13T13:03:23Z", "metrics": { "reactions": 77, "comments": 27 }, "labels": [ "enhancement", "area:mcp" ], "author": "ale-ayestaran-ai", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/36024", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-583f4b113115" }, { "tier": "triage-lead", "rankScore": 35, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:65961", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[MODEL] Claude verbose code comments by default — ignores instructions to stop.", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports - [x] This report does NOT contain sensitive information (API keys, passwords, etc.) ### Type of Behavior Issue Persistent bad behavior. Claude ignores my instructions or configuration. ### What You Asked Claude to Do ### Description Claude Code adds far too many code comments by default. The comments are mostly redundant, restating what the adjacent code already makes obvious or simply making references to the chat with Claude itself, leaking its chain of thoughts. It happens on every language, every model. Crucially, this default persists even when explicitly told to stop: - A clear, mandatory rule in `CLAUDE.md` does not reliably suppress it. - Reinforcing the rule via the memory system does not stop it either. I suppose the core problem is that verbose commenting is the **out-of-the-box default**, and that default is strong enough to override explicit user instructions. Users shouldn't have to stack a CLAUDE.md rule + memory entries + enforcement hooks just to get clean code, and that still working partially. ### Environment - Claude Code - Model: claude-opus-4-8, also verified on Opus 5 and Sonnet 5. ### What Claude Actually Did Contant verbose code commenting. ### Expected Behavior Restrained commenting as the **default** — comment only genuinely non-obvious constraints or \"why\" decisions, not self-evident \"what.\" And when a project instruction says to minimize comments, that instruction should be reliably respected. ### Actual behavior Reflexive explanatory comments on most code output, even when instructed otherwise. Requires constant manual cleanup or cleanup sessions with other models. ### Files Affected ```shell all ``` ### Permission Mode Accept Edits was ON (auto-accepting changes) ### Can You Reproduce This? Yes, every time. Happens pretty much on every session. ### Steps to Reproduce Just ask it to write code ### Claude Model Opus, Sonnet, Fable ### Relevant Conversation ```markdown Some comment examples: // A contribution ID collided with one owned by someone else, or a channel kind that doesn't match it. // Must stay below CHUNK_WORDS — the loop steps by the difference. // Ollama answers empty text with 200 and no vector, which would read as a model fault. // Unwrapped this is a bare \"fetch failed\" — no URL, no reason. The usual cause is a container pointing at 127.0.0.1 instead of host.docker.internal. // Another service on that port answers 200 with HTML, and a raw parse error names neither it nor the URL. // Asked, never assumed — no path may fall back to the column default. ``` ### Impact High - Significant unwanted changes. ### Claude Code Version 2.1.228 ### Platform Anthropic API ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/65961", "createdAt": "2026-06-07T00:38:42Z", "updatedAt": "2026-08-13T13:10:03Z", "timestamp": "2026-08-13T13:10:03Z", "metrics": { "reactions": 108, "comments": 10 }, "labels": [ "bug", "area:model", "model" ], "author": "bhuvarloka", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/65961", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-fe0a250a2d68" }, { "tier": "triage-lead", "rankScore": 35, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:67435", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Timezone displayed as \"Europe/Kiev\" instead of \"Europe/Kyiv\"", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Description: The Usage panel in Claude Code displays the timezone as Europe/Kiev, which is the deprecated IANA timezone identifier. Since tzdata 2022b, the correct identifier is Europe/Kyiv, reflecting Ukraine's official romanization adopted internationally. Root cause (likely): The application is either using an outdated tzdata version predating 2022b, or the legacy identifier Europe/Kiev is hardcoded somewhere in the display logic. References: IANA tzdata 2022b changelog: https://mm.icann.org/pipermail/tz-announce/2022-August/000073.html ### What Should Happen? Expected behavior: Timezone is displayed as Europe/Kyiv Actual behavior: Timezone is displayed as Europe/Kiev Environment: ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Steps to reproduce: Open Claude Code Run /usage Observe the timezone label under \"Current session\" and \"Current week\" Expected behavior: Timezone is displayed as Europe/Kyiv Actual behavior: Timezone is displayed as Europe/Kiev Environment: Tool: Claude Code Timezone: Europe/Kyiv (system) ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.170 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/67435", "createdAt": "2026-06-11T09:20:09Z", "updatedAt": "2026-08-13T16:33:49Z", "timestamp": "2026-08-13T16:33:49Z", "metrics": { "reactions": 56, "comments": 9 }, "labels": [ "bug", "platform:windows", "area:tui" ], "author": "AkopyanBogdan", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/67435", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-cdb057fe9d13" }, { "tier": "triage-lead", "rankScore": 35, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:24649", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "When exactly will Codex fix the recent slowdown and quality degradation?", "text": "Codex has felt noticeably slower and less capable over the past several days. The slowdown and quality degradation started over the weekend, and now it is already Tuesday, but the issue still does not appear to be fixed. The main problems I am seeing are: - Tasks that used to finish much faster are now taking significantly longer. - The quality of the output has become noticeably worse, especially on coding and debugging tasks. - Some tasks now waste a large amount of time and usage, while still producing results that need to be reverted or redone. - As a $200/month Pro subscriber, this experience feels very disappointing and not worth the cost right now. Codex is serving a global market, so it should be able to provide stable 24/7 operation. If users in California cannot reliably use Codex during normal daytime hours or over the weekend, what about users in the Eastern Hemisphere? Is there enough operational coverage during weekends and off-hours to monitor and maintain service quality? This is not just a small inconvenience for paying users. Codex needs to meet basic expectations for stability, speed, and output quality. Could the team please provide a clear update on whether this slowdown and quality regression is known, whether it is being actively investigated, and when users can expect normal performance to be restored? Please prioritize this urgently. Right now, the experience does not feel acceptable for a paid Pro user, and basic customer expectations are not being met.", "url": "https://github.com/openai/codex/issues/24649", "createdAt": "2026-05-26T21:42:14Z", "updatedAt": "2026-08-13T02:52:48Z", "timestamp": "2026-08-13T02:52:48Z", "metrics": { "reactions": 16, "comments": 9 }, "labels": [ "bug", "model-behavior", "performance" ], "author": "GGBondBlueWhale", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/24649", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-85baf6f4ba4c" }, { "tier": "triage-lead", "rankScore": 34, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:55623", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] .devcontainer/init-firewall.sh: statsig.anthropic.com fails DNS resolution, aborts container startup", "text": "## Summary `.devcontainer/init-firewall.sh` includes `statsig.anthropic.com` in its allowlist (line 71 on `main`), but that hostname has no public DNS records. The script treats any unresolvable domain as fatal (`exit 1`), so the devcontainer's `postStartCommand` fails and VS Code reports container setup as failed. ## Reproduction 1. Open the upstream `.devcontainer` (or any fork that uses the unmodified `init-firewall.sh`) in VS Code Dev Containers. 2. Container builds, then `postStartCommand` runs `init-firewall.sh`. 3. The resolution loop hits `statsig.anthropic.com`: ``` $ dig +short statsig.anthropic.com (no output) ``` 4. Script logs `ERROR: Failed to resolve statsig.anthropic.com` and exits 1. 5. VS Code reports: `postStartCommand from devcontainer.json failed with exit code 1`. Relevant log excerpt: ``` [ERROR] Failed to resolve statsig.anthropic.com Stop (1035 ms): Run in container: /bin/sh -c sudo /usr/local/bin/init-docker-socket.sh && sudo /usr/local/bin/init-firewall.sh postStartCommand from devcontainer.json failed with exit code 1. Skipping any further user-provided commands. ``` ## Verification ``` $ dig +short statsig.anthropic.com # $ dig +short statsig.com # resolves $ dig +short api.statsig.com # resolves ``` `statsig.anthropic.com` does not appear to be a public hostname (no A, no CNAME). It may be an internal-only DNS name that leaked into the public template, or a stale entry. ## Suggested fix Either: - Remove `statsig.anthropic.com` from the domain list (`statsig.com` is already present at line 72 of the same file), **or** - Make the resolution loop tolerant: log a warning and `continue` instead of `exit 1`, so a single unresolvable entry doesn't kill container startup. A diff for the tolerant version: ```diff - if [ -z \\\"\\$ips\\\" ]; then - echo \\\"ERROR: Failed to resolve \\$domain\\\" - exit 1 - fi + if [ -z \\\"\\$ips\\\" ]; then + echo \\\"WARN: Failed to resolve \\$domain — skipping\\\" + continue + fi ``` ## Environment - claude-code: 2.1.126 - VS Code Dev Containers extension: 0.457.0 - Host: macOS 26.3.1 - File: `.devcontainer/init-firewall.sh` @ `main`, lines 71 (allowlist entry) and 108–113 (fatal-exit logic)", "url": "https://github.com/anthropics/claude-code/issues/55623", "createdAt": "2026-05-02T17:05:23Z", "updatedAt": "2026-08-13T17:28:28Z", "timestamp": "2026-08-13T17:28:28Z", "metrics": { "reactions": 17, "comments": 5 }, "labels": [ "bug", "has repro", "platform:vscode", "area:sandbox" ], "author": "FournyP", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/55623", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-2a7b06133374" }, { "tier": "triage-lead", "rankScore": 34, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:31553", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex VS Code extension stopped auto-including IDE context after update", "text": "### What version of the IDE extension are you using? 26.623.141536 ### What subscription do you have? Pro ### Which IDE are you using? VS Code remote/container (.vscode-server) ### What platform is your computer? Windows 11, Docker ### What issue are you seeing? Date observed: July 8, 2026 Previously working: July 7, 2026 Behavior before: prompts automatically included open file and selected text Behavior now: open file and highlighted selection are no longer referenced unless manually added ### What steps can reproduce the bug? Select text in an open file in the IDE and prompt agent \"What text have I selected?\" ### What is the expected behavior? Codex IDE extension should automatically include open files and selected text, per docs ### Additional information - Explicit commands still exist: Add to Codex Thread / Add File to Codex Thread - No documented setting found to disable automatic IDE context - Shared config had model pinned to gpt-5.4", "url": "https://github.com/openai/codex/issues/31553", "createdAt": "2026-07-08T09:26:15Z", "updatedAt": "2026-08-12T21:27:05Z", "timestamp": "2026-08-12T21:27:05Z", "metrics": { "reactions": 12, "comments": 17 }, "labels": [ "bug", "windows-os", "extension" ], "author": "ps-bobbykotzev", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/31553", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-963d48ad6ec3" }, { "tier": "triage-lead", "rankScore": 34, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:35156", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex not showing diff", "text": "### What version of the IDE extension are you using? 26.721.30844 ### What subscription do you have? Plus ### Which IDE are you using? Vs code ### What platform is your computer? _No response_ ### What issue are you seeing? I cant´t see the codex diff , i click the button \"Review\" to see what have changed but this \"Oops, an error has occurred\" appears in the screen whit a button with the text \"try again\" I click it and the window changes showing me in the screen \"No diff available\" ### What steps can reproduce the bug? . ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/35156", "createdAt": "2026-07-24T11:26:23Z", "updatedAt": "2026-08-13T16:24:52Z", "timestamp": "2026-08-13T16:24:52Z", "metrics": { "reactions": 37, "comments": 5 }, "labels": [ "bug", "code-review", "extension" ], "author": "garzastrabajo", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/35156", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-2e75068893d1" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:49655", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Desktop update fails with 0x80073CF6 when CoworkVMService is running (Windows)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? **Claude Desktop fails to update/reinstall on Windows with HRESULT 0x80073CF6 (ERROR_PACKAGES_IN_USE) when CoworkVMService is running, even after Claude Desktop is fully closed. The AppX installer cannot delete the Helium virtual registry hive files because CoworkVMService holds kernel-level locks on them: - C:\\Users\\\\AppData\\Local\\Packages\\Claude_pzs8sxrjxfjjc\\SystemAppData\\Helium\\User.dat - C:\\Users\\\\AppData\\Local\\Packages\\Claude_pzs8sxrjxfjjc\\SystemAppData\\Helium\\UserClasses.dat These locks cannot be released without a full system reboot, making it impossible to update Claude while any server/service is running.** ### What Should Happen? The Claude installer should automatically stop CoworkVMService and related processes (cowork-svc, parsecd, chrome-native-host) before attempting the MSIX package update, then restart them after installation completes. ### Error Messages/Logs ```shell MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6 AppX deployment log: - Error deleting Helium\\User.dat: 0x20 (ERROR_SHARING_VIOLATION) - Error deleting Helium\\UserClasses.dat: 0x20 (ERROR_SHARING_VIOLATION) - Error 0xD0074005: Cannot notify BrokerInfrastructure service about package state change ``` ### Steps to Reproduce 1. Install Claude Desktop (MSIX) with Cowork feature enabled 2. Launch Claude Desktop — CoworkVMService starts automatically 3. Close Claude Desktop completely 4. Download and run the new Claude Setup.exe installer 5. Installation fails with: AddPackage failed with HRESULT 0x80073CF6 Workaround (requires manual step before every update): Stop-Service CoworkVMService -Force Stop-Process -Name cowork-svc, parsecd, chrome-native-host -Force -ErrorAction SilentlyContinue Claude Code Version Claude Desktop 1.3036.0.0 Operating System Windows 11 Pro 10.0.26100 Terminal/Shell PowerShell (Administrator) ### Claude Model Other ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Claude Desktop 1.3036.0.0 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Terminal.app (macOS) ### Additional Information - This is a recurring issue: every Claude Desktop update requires a full system reboot if CoworkVMService has been running - The Helium hive files are locked at kernel level — handle64.exe (Sysinternals) cannot detect the lock - reg unload fails with \"Access is denied\" even from Administrator - Only a full system restart releases the kernel-level hive locks - Users running servers or long-running processes cannot reboot just to update Claude", "url": "https://github.com/anthropics/claude-code/issues/49655", "createdAt": "2026-04-17T02:13:04Z", "updatedAt": "2026-08-13T17:51:46Z", "timestamp": "2026-08-13T17:51:46Z", "metrics": { "reactions": 10, "comments": 20 }, "labels": [ "bug", "platform:windows", "area:cowork", "area:installation", "area:desktop" ], "author": "jun-ho-hong", "state": "open", "assignees": [], "change": "new" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/49655", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-12ab5911c33f" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:54750", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Bug: Claude Code current session limit reaches 100% despite low visible local session usage", "text": "# Bug: Claude Code shows current session limit exhausted despite very low visible local session usage ## Summary Claude Code / Claude Desktop reported the **current session limit as 100% used** and blocked further Claude Code usage, even though the usage visible locally in Claude Code and local transcripts did not appear to justify exhausting a Max 20x current-session limit. This could be either: 1. A **usage accounting / attribution bug**, where the current session limit is being computed incorrectly or includes usage not represented in local Claude Code usage views. 2. A **security / token attribution issue**, where usage from another device/session/token is being charged to the same Claude Code account but is not visible in local Claude Code transcripts. At minimum, Claude Code's `/usage` UI appears insufficient for diagnosing why the current session was exhausted. ## Environment - Claude Code version: `2.1.123` - OS: macOS `26.2` (`arm64`) - Node.js: `v22.17.0` - npm: `10.9.2` - Plan shown in Claude UI: Max 20x - Timezone: Europe/Madrid - Date observed: 2026-04-29 ## What happened At approximately `2026-04-29 18:25 CEST`, Claude Desktop and Claude Code showed: - Current session: `100% used` - Reset: around `21:40 Europe/Madrid` - Current week, all models: `60% used` - Current week, Sonnet only: `1% used` In Claude Code `/usage`, the visible local session summary was small: ```text Session Total cost: $0.76 Total duration (API): 53s Total duration (wall): 2h 53m 5s Total code changes: 0 lines added, 0 lines removed Usage by model: claude-haiku-4-5: 370 input, 14 output, 0 cache read, 0 cache write claude-opus-4-7: 21 input, 2.5k output, 436.2k cache read, 76.9k cache write Current session: 100% used Resets 9:40pm (Europe/Madrid) Current week (all models): 60% used Current week (Sonnet only): 1% used ``` The same local Claude Code transcript recorded the hard limit after a trivial prompt: ```text timestamp=2026-04-29T16:26:16.363Z user prompt=\"a\" timestamp=2026-04-29T16:26:16.859Z message=\"You've hit your limit · resets 9:40pm (Europe/Madrid)\" ``` This makes the limit feel disconnected from the visible local Claude Code usage. ## Local transcript usage cross-check I also inspected local Claude Code transcript usage using `ccusage`: ```bash npx ccusage@latest blocks --json ``` Relevant blocks for the same day: ```text 2026-04-29T04:00:00Z - 2026-04-29T09:00:00Z totalTokens=363,679,444 cacheReadInputTokens=358,827,700 cacheCreationInputTokens=4,361,929 outputTokens=478,605 models=claude-opus-4-7, claude-haiku-4-5, claude-sonnet-4-6 2026-04-29T09:00:00Z - 2026-04-29T14:00:00Z totalTokens=214,817,570 cacheReadInputTokens=211,368,028 cacheCreationInputTokens=3,297,689 outputTokens=151,103 models=claude-opus-4-7, claude-opus-4-6 2026-04-29T14:00:00Z - 2026-04-29T19:00:00Z isActive=true totalTokens=35,577,623 cacheReadInputTokens=34,247,311 cacheCreationInputTokens=1,269,568 outputTokens=60,358 models=claude-opus-4-7, claude-haiku-4-5 ``` The active block corresponds to approximately `16:00-21:00 CEST`. At the time Claude Code reported the current session as exhausted, local transcript usage for the active block was only about `35.6M` tokens according to `ccusage`. I understand `ccusage` is not an official Anthropic source of truth, but the discrepancy is large enough that the CLI should expose enough attribution/debug information to explain it. ## Expected behavior One of the following should happen: - If current-session usage is exhausted, Claude Code `/usage` should show which surfaces/sessions/tokens/models contributed enough usage to exhaust it. - If usage from Claude Desktop, claude.ai, Claude in Chrome, other devices, or other Claude Code tokens is included, `/usage` should make that explicit and provide a breakdown or at least a clear attribution category. - If the session total shown by Claude Code is not the same accounting scope as \"Current session 100% used\", the UI should label those scopes clearly. - A trivial prompt after a low visible local session total should not immediately hit the limit unless other usage is clearly attributed. ## Actual behavior Claude Code showed: - A very small visible local session summary (`$0.76`, ~436k cache read in the visible session summary). - At the same time, `Current session: 100% used`. - The next trivial prompt immediately produced a hard limit error. - Local transcript usage for the active block did not explain the current-session exhaustion. ## Why this matters From the user's perspective, there is no way to tell whether: - the current-session usage calculation is wrong, - usage from another Claude surface is being included, - a stale/old Claude Code process is consuming usage, - another Claude Code authorization token is consuming usage, or - the account/session has been compromised. This makes it difficult to distinguish a product bug from a security incident. ## Related issues found I searched existing `anthropics/claude-code` issues and found several likely related reports: - https://github.com/anthropics/claude-code/issues/38335 — Max plan 5-hour session limit exhausted abnormally fast since March 23, 2026; users report 21% to 100% jumps on a single prompt. - https://github.com/anthropics/claude-code/issues/37394 — Max plan hitting limits extremely fast; user reports one message plus two Python script calls jumping usage from 0% to 24%. - https://github.com/anthropics/claude-code/issues/42052 — Max 20x plan reaches 100% after ~2 hours of light work; explicitly links several related abnormal usage drain reports. - https://github.com/anthropics/claude-code/issues/41788 — Max 20 plan exhausted within ~70 minutes after reset; suspected server-side cached/thinking-token accounting or prompt-cache invalidation. - https://github.com/anthropics/claude-code/issues/41930 — broader report on abnormal usage limit drain across paid tiers, including possible prompt-caching and session-resume causes. This issue may overlap with those, but the specific additional concern here is the **diagnostic mismatch**: Claude Code's local `/usage` and transcript-derived usage do not explain why the global current-session limit is exhausted. The product should expose enough attribution to determine whether usage came from this local Claude Code session, another Claude surface, another token/device, or a server-side accounting bug. ## Suggested improvements Please consider adding one or more of: - A server-side usage attribution breakdown in `/usage`, grouped by product surface: Claude Code, Claude Desktop, claude.ai, Claude in Chrome, etc. - A breakdown by active Claude Code token/session/device where possible. - A clearer distinction between \"this local Claude Code session\" and \"global current 5-hour account/session limit\". - A warning when usage contributing to the current session is coming from outside the local machine/transcript. - A support/debug export command that produces a sanitized usage report users can attach to Anthropic support. ## Attachments available I can attach a screenshot of Claude Code `/usage` showing: - Local session total cost: `$0.76` - Current session: `100% used` - Reset: `9:40pm Europe/Madrid` - Current week all models: `60% used` - Current week Sonnet only: `1% used` I can also provide a private support report with account/session screenshots and sanitized local transcript excerpts. I am intentionally not including account IDs, authorization tokens, bearer tokens, or private project names in this public issue.", "url": "https://github.com/anthropics/claude-code/issues/54750", "createdAt": "2026-04-29T17:03:11Z", "updatedAt": "2026-08-13T07:38:46Z", "timestamp": "2026-08-13T07:38:46Z", "metrics": { "reactions": 11, "comments": 17 }, "labels": [ "bug", "platform:macos", "area:cost" ], "author": "Troskiev83", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/54750", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-6987eb9b2991" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:82506", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Possible Claude Max usage bug: session limit consumed without using", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Claude appears to have a serious usage bug. I haven’t used Claude for three days, but my limits keep getting consumed automatically after every reset. I’ve seen several users on X reporting the same issue, so this may be a wider problem with usage being incorrectly counted or shared across accounts. ### What Should Happen? Claude should not autmaticly hit limits ### Error Messages/Logs ```shell ``` ### Steps to Reproduce No steps to products its just hit limits ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.220 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/82506", "createdAt": "2026-07-30T07:55:17Z", "updatedAt": "2026-08-13T08:21:25Z", "timestamp": "2026-08-13T08:21:25Z", "metrics": { "reactions": 8, "comments": 29 }, "labels": [ "bug" ], "author": "TchabaTech", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/82506", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-ebc92c6ced87" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:astral-sh/uv:issue:11273", "source": "github", "group": "developer-infrastructure", "project": "astral-sh/uv", "kind": "issue", "title": "Add environment variable to always use `--active` flag", "text": "### Summary The new `--active` flag (#11189) is a great addition and I think it goes some way to allow `uv` and `pyenv` to work better together (see #6204). Would it be possible to add a new environment variable to make that flag the default? For example, the PR suggested something like `UV_PROJECT_ENVIRONMENT=ACTIVE` but could also be `UV_ACTIVE=1`. Or maybe this already works? If so, it's not clear from the documentation. ### Example _No response_", "url": "https://github.com/astral-sh/uv/issues/11273", "createdAt": "2025-02-06T04:51:21Z", "updatedAt": "2026-08-13T09:05:16Z", "timestamp": "2026-08-13T09:05:16Z", "metrics": { "reactions": 26, "comments": 16 }, "labels": [ "enhancement", "configuration" ], "author": "albireox", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/astral-sh/uv/issues/11273", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/developer-infrastructure/uv.html#signal-86745c2e4274" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:23200", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support headless remote Linux hosts for Codex mobile without requiring the desktop app to stay online", "text": "## Summary Codex mobile is very useful as a control layer, but it is currently limited when the active Codex environment depends on a personal desktop machine staying online. Many development workflows run primarily on always-on Linux servers accessed through SSH, while the desktop app is only a local access point. It would be valuable to support a headless or remote-host mode where Codex mobile can connect to an always-on Linux host directly, without requiring the Windows desktop app to remain powered on, awake, and running. This is related to #23082, but this request is specifically about not requiring a desktop host to remain online once the real working environment is an always-on remote Linux host. ## Problem For users whose projects live on remote Linux servers, the desktop machine is not always the most reliable host for long-running Codex work. A personal workstation may be shut down, asleep, restarted, or unavailable, while the actual development servers remain online continuously. This creates friction in workflows such as: 1. Starting a long-running Codex task on a remote server. 2. Leaving the desktop machine. 3. Continuing approvals, follow-ups, checks, and reviews from mobile. 4. Keeping the task alive even if the local desktop is turned off. Today, if the desktop app is the required bridge, the user may need to keep a personal machine running only so an existing Codex conversation can continue. ## Feature request Add support for Codex mobile to connect to an always-on remote Linux host, ideally through a secure headless Codex host, daemon, or remote-host registration flow. ## Suggested design - Allow a Linux server to be registered as a Codex host. - Let the ChatGPT mobile app show registered hosts independently from desktop app availability. - Allow users to start, resume, monitor, and approve Codex work from mobile on that remote host. - Keep credentials, files, shell access, and project context on the remote host. - Clearly show the active host, project path, and permission boundary before every command approval. - Support long-running tasks even when the desktop app is offline. - Optionally allow a desktop app to remain a convenience UI, but not the only bridge. ## Security and UX safeguards - Mobile should act as a secure control and approval layer, not as a place where SSH keys or tokens are copied. - Every approval should clearly identify the remote host and project context. - Host status should be explicit: online, offline, disconnected, waiting for approval, or task running. - Admins should be able to revoke mobile access to a host. - Sensitive hostnames, usernames, IPs, and paths should not be required in the UI or issue reports. ## Expected benefit This would make Codex mobile much more useful for developers, DevOps users, infrastructure teams, and anyone whose real work happens on remote Linux environments rather than on a personal desktop machine. Suggested labels, if available: `enhancement`, `mobile`, `remote`, `ssh`, `headless`, `linux` ## Redaction check This request intentionally uses only generic examples. It does not include real hostnames, IP addresses, usernames, private repository names, internal project names, credentials, or environment-specific paths.", "url": "https://github.com/openai/codex/issues/23200", "createdAt": "2026-05-17T21:51:27Z", "updatedAt": "2026-08-12T14:10:52Z", "timestamp": "2026-08-12T14:10:52Z", "metrics": { "reactions": 48, "comments": 17 }, "labels": [ "enhancement", "iOS", "remote" ], "author": "chac4l", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/openai/codex/issues/23200", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-b1e76acc0ad1" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:29235", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex asks for permission despite full access and approval prompts disabled", "text": "## Summary Codex repeatedly asks the user for permission before ordinary actions even when the thread is configured with full filesystem access and approval prompts disabled. ## User impact This breaks flow across threads. The user expects Codex to proceed with normal local reads, edits, commands, and safe local commands, but the assistant keeps interrupting to ask for permission. ## Observed behavior - In multiple Codex threads, the assistant asks for permission before continuing. - This happens even when the session has unrestricted filesystem access. - This happens even when approval prompts should not be requested. - In the current thread, the assistant had to be corrected with: \"you have full acces why do you keep asking for permission\" and then clarified that this is happening \"in all my threads\". ## Expected behavior When a thread has full access and approval prompts disabled, Codex should proceed without asking for permission for ordinary, non-destructive local work. Codex should still ask for explicit confirmation for actions with major external or destructive consequences, such as: - deleting user data - force-resetting git history - sending email - publishing changes - modifying calendars or external accounts - making irreversible changes outside the requested scope ## Environment evidence from current thread - Surface: Codex desktop app, projectless local thread - Date observed: 2026-06-20 - Filesystem access: unrestricted / full access - Approval behavior expected: no approval prompts for shell commands - Active permission profile presented to the assistant included unrestricted filesystem access and instructions not to request escalation. ## Likely cause The assistant appears to be over-applying a permission-request behavior despite the active thread configuration. This may be one of: - model behavior not honoring the current approval policy - stale permission assumptions carried across threads - UI/tooling exposing full access while the assistant still believes approval is required - conflicting instruction handling around tool safety ## Reproduction steps 1. Open a Codex thread configured with full filesystem access. 2. Ensure approval prompts are disabled / not required. 3. Ask Codex to perform ordinary local work, such as reading files, editing a file, running a safe command, or installing a local dependency. 4. Observe that Codex asks for permission anyway. ## Requested fix Codex should align its behavior with the active permission profile: - If approval prompts are disabled, do not ask for approval for ordinary local operations. - Only ask for confirmation when the action itself is destructive, externally visible, or irreversible. - Make the assistant aware that `approval_policy=never` means it should not request escalation or permission prompts.", "url": "https://github.com/openai/codex/issues/29235", "createdAt": "2026-06-20T15:46:16Z", "updatedAt": "2026-08-13T04:29:25Z", "timestamp": "2026-08-13T04:29:25Z", "metrics": { "reactions": 17, "comments": 3 }, "labels": [ "bug", "model-behavior", "sandbox", "app" ], "author": "mrlightsource-create", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/29235", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-54f8cdd5df1c" }, { "tier": "triage-lead", "rankScore": 33, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:30408", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP server processes leak: per-thread processes never cleaned up (9+ GB RSS)", "text": "## Bug description Codex app-server spawns a full set of global MCP server processes for each new thread/conversation, but **never kills them when threads are archived or closed**. Over time, orphaned MCP processes accumulate unboundedly. ## Environment - Codex Desktop: 0.142.3 (macOS, Apple Silicon) - OS: macOS 15.x, 64 GB RAM ## Steps to reproduce 1. Configure global MCP servers in `~/.codex/config.toml` (e.g. `playwright`, `davinci-resolve`, `node_repl`) 2. Open Codex Desktop, create ~25 threads over a session 3. Close/archive threads as normal 4. Check process list ## Expected behavior MCP server processes should be cleaned up when the owning thread is closed or archived. At most one set of MCP processes should exist per actively-used server. ## Actual behavior After 25 threads, observed **133 orphaned MCP processes** consuming **~9.3 GB RSS**: | MCP Server | Orphaned Processes | RSS | |---|---|---| | `playwright` (npm + node) | 52 | 2.9 GB | | `davinci-resolve` (python) | 26 | 3.5 GB | | `node_repl` | 26 | 266 MB | | npm exec wrappers | 29 | 2.6 GB | All processes had PPID = app-server PID. The app-server holds them indefinitely. ## Root cause The app-server does not track which MCP processes belong to which thread, and has no lifecycle management to kill MCP processes when threads end. There is also no `idle_timeout`, `reuse`, or `shared` config option for MCP servers. ## Workaround - Manually kill orphaned processes: `pkill -P -f \"playwright-mcp|davinci-resolve\"` - Remove rarely-used MCP servers from global config and add them per-project instead ## Suggested fix - Track MCP process ownership per-thread - Kill MCP processes when the owning thread is closed/archived - Alternatively, add a `shared` or `reuse` mode so all threads share a single MCP process instance - Consider an `idle_timeout` option to auto-kill MCP processes after N minutes of no use", "url": "https://github.com/openai/codex/issues/30408", "createdAt": "2026-06-28T03:40:13Z", "updatedAt": "2026-08-13T02:37:01Z", "timestamp": "2026-08-13T02:37:01Z", "metrics": { "reactions": 8, "comments": 29 }, "labels": [ "bug", "mcp", "app", "app-server", "performance" ], "author": "kkkayye", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/30408", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-7a7ff0ece5a4" }, { "tier": "triage-lead", "rankScore": 32, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:14920", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature Request] Add ability to disable individual Claude plugin skills", "text": "**Bug Description** I want to be able to disable claude plugin skills individually - for example, I don't find commit-commands:commit-push-pr or commit-commands:clean_gone useful, I just want :commit **Environment Info** - Platform: darwin - Terminal: iTerm.app - Version: 2.0.75 - Feedback ID: b9c26774-de01-49c2-98ff-767d9bcb65bf", "url": "https://github.com/anthropics/claude-code/issues/14920", "createdAt": "2025-12-20T23:32:50Z", "updatedAt": "2026-08-13T08:25:14Z", "timestamp": "2026-08-13T08:25:14Z", "metrics": { "reactions": 86, "comments": 15 }, "labels": [ "enhancement", "platform:macos", "area:core" ], "author": "petergeneric", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/14920", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-2c41b0990a49" }, { "tier": "triage-lead", "rankScore": 32, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:18906", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI: support Markdown math rendering for inline and block LaTeX", "text": "### What version of Codex is running? Observed in the current Codex terminal workflow. I do not have a precise version string to attach here. ### Which model were you using? Observed while using Codex in the terminal UI. ### What platform is your computer? macOS on Apple Silicon in a terminal-based Codex workflow. ### What issue are you seeing? Codex renders regular Markdown reasonably well in the terminal UI, but LaTeX math in Markdown is not rendered. In practice, inline math such as `$W = W_0 + BA$` and block math such as: ```md $$ q^T k = (q^C)^T k^C + (q^R)^T k^R $$ ``` show up as raw Markdown/LaTeX source instead of readable equations. This makes Codex less useful for: - ML and math-heavy notes - paper reading - algorithm derivations - technical documentation with equations ### What feature would you like? Support Markdown math rendering in the Codex terminal UI, ideally for both: - inline math: `$...$` - block math: `$$...$$` Possible implementation directions: - render to a terminal-friendly plain-text or Unicode pretty-printed form - add a math-aware Markdown parsing/rendering stage - optionally support KaTeX-compatible parsing before terminal rendering Even a partial first step would help: - preserve math blocks as visually distinct blocks - improve spacing/escaping for common expressions - avoid broken rendering for common LaTeX patterns ### Why this matters Codex is especially useful for coding, research, and technical writing workflows. In those workflows, mathematical notation is common. Right now the terminal UI handles prose and code, but not equations, which creates a gap for engineering and research use cases. ### Reproduction 1. Open Codex in the terminal UI. 2. Ask it to write or display Markdown containing inline and block LaTeX math. 3. Observe that the expressions are not rendered as readable equations. ### Expected behavior Math expressions should display in a readable rendered form, or at minimum in a terminal-friendly normalized representation that is much easier to read than raw LaTeX source. ### Additional context This request is specifically about the terminal / TUI rendering path, not browser-based Markdown renderers.", "url": "https://github.com/openai/codex/issues/18906", "createdAt": "2026-04-21T23:44:32Z", "updatedAt": "2026-08-13T12:35:51Z", "timestamp": "2026-08-13T12:35:51Z", "metrics": { "reactions": 22, "comments": 14 }, "labels": [ "enhancement", "TUI" ], "author": "water2078", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/18906", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-7f269b23497d" }, { "tier": "triage-lead", "rankScore": 32, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:20851", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Feature request: first-class Computer Use support from the Codex CLI", "text": "### Problem Computer Use is currently exposed as a Codex desktop/app plugin, but it is not presented as a first-class, supported CLI capability. The local implementation appears to be a bundled MCP helper: ```text computer-use -> ./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp ``` On my machine, `codex mcp list` shows the `computer-use` server enabled from the OpenAI-bundled plugin cache, and the plugin metadata describes it as controlling Mac apps through screenshots/accessibility with user approval. The Codex CLI itself has general `mcp` commands, but `codex --help` does not expose a clear supported Computer Use workflow, permission setup, diagnostic path, or Desktop-bridge path for CLI sessions. This is related to the narrower runtime bug in #19544, but the request here is a product/API request: make Computer Use an explicitly supported Codex CLI feature, not a Desktop-only capability that users discover indirectly through bundled MCP state. ### Why this matters For automation-heavy workflows, the CLI is where agents are launched, resumed, scripted, and supervised. If the same agent can use shell, files, web search, and MCP tools from the terminal, it should also have a clear way to use Computer Use from the terminal when the user grants the necessary macOS permissions. A CLI-first workflow would let users run tasks like: ```sh codex \"Use Computer Use to inspect Chrome and summarize the current page\" codex exec \"Use Computer Use to open Xcode, run the current project, and report failures\" ``` without needing to start the task inside the Desktop app first. ### Current local evidence Environment from a current macOS install: ```text Codex app: 26.429.30905 Codex CLI: codex-cli 0.128.0 Computer Use plugin: openai-bundled/computer-use/1.0.770 macOS: 26.2 arm64 ``` Observed wiring: ```json { \"mcpServers\": { \"computer-use\": { \"command\": \"./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient\", \"args\": [\"mcp\"], \"cwd\": \".\" } } } ``` The helper bundle identifiers are: ```text com.openai.sky.CUAService com.openai.sky.CUAService.cli ``` The helper is signed by OpenAI and has parent launch constraints, so the launch context appears to matter for CLI support and permission behavior. ### Requested behavior Please provide an official CLI path for Computer Use, including: - a documented way to enable/use Computer Use from `codex` and `codex exec` - a diagnostic command or doctor flow for app permissions, TCC state, helper launch context, and MCP availability - a clear user approval flow for terminal-launched Computer Use actions - actionable errors when the CLI is launched from an unsupported context - parity between the official CLI install path and any app-bundled CLI path Possible shapes: ```sh codex computer-use doctor codex computer-use allow \"Google Chrome\" codex --enable computer-use \"Inspect Safari and summarize the page\" codex exec --enable computer-use \"List running apps and stop\" ``` The exact command shape is less important than having a supported, documented contract. ### Security requirements Computer Use from the CLI should keep the same safety posture as Desktop: - explicit per-app or per-session permissioning - visible action approval for sensitive clicks/typing - auditability of screenshots, clicks, typing, and app targets - no silent escalation from shell access to desktop control - clear behavior for non-interactive `codex exec` when approval is required ### Acceptance criteria - A fresh official Codex CLI install can use Computer Use after the required user approvals. - `codex mcp list` and the actual CLI runtime agree on whether Computer Use is usable. - A minimal CLI task can call `computer-use/list_apps` successfully. - A CLI task can inspect and act on an approved app window with the same safety prompts as Desktop. - Unsupported launch contexts fail with a clear diagnostic instead of a low-level Apple Event, code-signing, or helper-start error.", "url": "https://github.com/openai/codex/issues/20851", "createdAt": "2026-05-03T07:14:03Z", "updatedAt": "2026-08-12T17:25:11Z", "timestamp": "2026-08-12T17:25:11Z", "metrics": { "reactions": 25, "comments": 14 }, "labels": [ "enhancement", "mcp", "CLI", "computer-use" ], "author": "its-DeFine", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/20851", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-7dfb664d6053" }, { "tier": "triage-lead", "rankScore": 32, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:37403", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[macOS][regression] Desktop cannot resume Remote Control / CLI thread: `already has an active writer` after latest update", "text": "## Summary After updating the ChatGPT Desktop client on macOS on **August 7, 2026**, an existing workflow that previously worked stopped working: - During off-hours, I use **ChatGPT mobile Remote Control** to continue a Codex CLI thread on my Mac. - During the day, I open the same thread in the **Desktop client** and continue from there. After the latest Desktop update, the Desktop/CLI handoff fails because the thread is reported as already having an active writer. This appears to be a regression in thread ownership / writer handoff between the Desktop-bundled app-server/runtime and the CLI/Remote Control runtime. ## Environment - Platform: macOS (iMac) - Standalone CLI: ```text codex-cli 0.147.0 ``` - ChatGPT Desktop bundled Codex runtime: ```text /Applications/ChatGPT.app/Contents/Resources/codex --version codex-cli 0.147.0-alpha.6.5 ``` - The issue started immediately after installing the latest ChatGPT Desktop update on August 7, 2026. - The same Remote Control / CLI / Desktop workflow worked before that update. ## Steps to reproduce 1. Keep Codex Remote Control enabled on the Mac. 2. Use ChatGPT mobile Remote Control to open/continue a Codex CLI thread. 3. Later, on the same Mac, try to resume/open that same thread from the Desktop client. 4. Observe that the thread cannot be resumed because another writer is considered active. ## Actual behavior The resume attempt fails with an error like: ```text Failed to resume session from ~/.codex/sessions/YYYY/MM/DD/rollout-...jsonl: thread/resume failed during TUI bootstrap: thread/resume failed: thread already has an active writer (code -32600) ``` A key observation: - With the Desktop client running, the thread hits the `already has an active writer` conflict. - If I **fully quit the Desktop client**, the same session can immediately be opened/resumed normally from the standalone CLI. The session JSONL itself therefore appears intact; the problem looks like writer ownership/lifecycle rather than session corruption. ## Expected behavior Remote Control is intended to let the same work continue across mobile and desktop usage. A thread used through Remote Control / CLI should be able to hand off cleanly to Desktop when the user returns to the Mac. Expected flow: ```text Mobile Remote Control / CLI thread ↓ user stops actively using mobile ↓ Desktop resumes the same thread ↓ ownership/writer handoff succeeds ``` The user should not need to disable Remote Control, kill app-server processes, fork the conversation, or create a new thread just to switch between mobile and Desktop. ## Impact This breaks a core daily workflow: - Desktop during work hours - Mobile Remote Control after work - Same Codex thread/context across both surfaces Because Remote Control needs to remain enabled, simply turning it off is not a practical workaround. ## Regression evidence The behavior changed immediately after the latest Desktop update. No CLI configuration or session files were changed at the time. The standalone CLI and Desktop-bundled runtime are different builds: ```text Standalone: 0.147.0 Desktop bundled: 0.147.0-alpha.6.5 ``` This may be related to stricter single-writer enforcement without a corresponding Desktop ↔ Remote Control ownership handoff. ## Privacy note The local username, exact session path, thread ID, repository/project names, and conversation contents are intentionally omitted. I can provide additional sanitized diagnostics if maintainers request them.", "url": "https://github.com/openai/codex/issues/37403", "createdAt": "2026-08-07T08:14:10Z", "updatedAt": "2026-08-13T09:54:31Z", "timestamp": "2026-08-13T09:54:31Z", "metrics": { "reactions": 10, "comments": 17 }, "labels": [ "bug", "app", "app-server", "remote" ], "author": "xkun1", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/37403", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-0c0944abf1d6" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:21867", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Add settings to hide token counter and version display in status line", "text": "## Preflight Checklist - [x] I have searched existing feature requests and found no duplicates - [x] This is a single feature request (not multiple bundled together) - [x] I have provided concrete use cases ## Problem Statement When using a custom `statusLine` configuration, Claude Code still displays built-in UI elements on the right side of the interface: - Token counter (\"0 tokens\" or \"X tokens\") - Version comparison (\"current: 2.1.25 · latest: 2.1.25\") There's no documented way to hide these elements for users who want a minimal or fully custom UI. ## Proposed Solution Add environment variables following the existing `CLAUDE_CODE_HIDE_*` pattern: ```json { \"env\": { \"CLAUDE_CODE_HIDE_TOKENS\": \"1\", \"CLAUDE_CODE_HIDE_VERSION\": \"1\" } } ``` ## Alternative Solutions A single setting for minimal UI could also work: ```json { \"env\": { \"CLAUDE_CODE_MINIMAL_STATUS_UI\": \"1\" } } ``` ## Priority **Medium** - Would be very helpful for users with custom status lines ## Feature Category **Configuration and settings** ## Use Case Example 1. **Streamers/demos** - Want clean UI without distracting numbers 2. **Custom statusLine users** - Already displaying context info their own way via the `statusLine` setting 3. **Minimal UI preference** - Users who find these elements unnecessary noise ## Additional Context ### Existing Precedent `CLAUDE_CODE_HIDE_ACCOUNT_INFO` already exists for hiding email/organization, so the pattern is established. ### Environment - Claude Code version: 2.1.25 - Platform: macOS", "url": "https://github.com/anthropics/claude-code/issues/21867", "createdAt": "2026-01-30T05:47:49Z", "updatedAt": "2026-08-13T11:04:19Z", "timestamp": "2026-08-13T11:04:19Z", "metrics": { "reactions": 31, "comments": 10 }, "labels": [ "enhancement", "platform:macos", "area:tui" ], "author": "coygeek", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/21867", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-0866abc5bb76" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:37183", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "RTL (Right-to-Left) text direction support", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Claude Code currently has no RTL support in its interface. For users who work in Hebrew, Arabic, or other RTL languages, this creates a significant usability problem: When Claude responds with mixed Hebrew/English text, the display breaks and becomes difficult to read There is no way to configure text direction in the conversation window Users have to \"guess\" what is written due to incorrect text rendering Request: Add RTL/bidirectional text support to the Claude Code interface (CLI + VSCode extension), similar to how VS Code handles RTL in the editor. This would benefit all users writing in Hebrew, Arabic, Persian, and other RTL languages. ### Proposed Solution Add CSS `direction: rtl` and `unicode-bidi: embed` support for the conversation pane, either: 1. Auto-detect based on the dominant language of each message 2. Add a user setting to force RTL mode globally 3. Apply per-paragraph bidi algorithm (Unicode Bidirectional Algorithm - UBA) This is standard browser/CSS behavior and should be relatively low-effort to implement in the VSCode extension UI. ### Alternative Solutions _No response_ ### Priority High - Significant impact on productivity ### Feature Category Interactive mode (TUI) ### Use Case Example 1. I work in Hebrew and English daily (Parallels reseller, Israel/MEA market) 2. Claude responds with mixed Hebrew/English text 3. The text renders LTR, making Hebrew unreadable — letters appear reversed and words break incorrectly 4. With RTL support, Hebrew users could read responses clearly without having to copy text to another app to understand it ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/37183", "createdAt": "2026-03-21T18:24:51Z", "updatedAt": "2026-08-13T05:48:28Z", "timestamp": "2026-08-13T05:48:28Z", "metrics": { "reactions": 34, "comments": 9 }, "labels": [ "enhancement", "area:tui", "area:a11y", "platform:vscode" ], "author": "eitan-kir", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/37183", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-ec301370d5f7" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:50884", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Let users remove stale/dead Remote Control environments from the claude.ai/code environment list", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement After running claude remote-control multiple times on my local machine and shutting each session down (Ctrl+C / closing the terminal), the old environments continue to appear in the environment list at claude.ai/code. The entries persist indefinitely with no way to remove them, even though none of them work anymore, clicking them leads to a dead/non-functional session. Over time, anyone who uses Remote Control regularly ends up with a long list of stale, non-functional environments in the web UI, making it hard to find the one active session among the dead ones. There is currently no affordance in the CLI or on the web to delete these stale entries. ### Proposed Solution Expected behavior: Users should be able to remove dead Remote Control environments from the list shown at claude.ai/code (and the mobile apps). Feature request: 1. **Remove from web UI** — A \"Remove\" / trash icon next to each entry in the environment list at claude.ai/code that deletes the stale environment from the list. This is the primary request. 2. **Bulk \"Clean up disconnected\" action** — A single button that removes all environments that are no longer online, for users who accumulate many of them. 3. **CLI command** — Something like claude remote-control --list and claude remote-control --revoke for users who prefer the terminal. 4. **Optional auto-cleanup** — After a configurable period of inactivity (e.g., 24h / 7d), stale environments are removed automatically. ### Why this matters - **UX / clutter**: The environment dropdown becomes unusable after normal daily use of Remote Control. There's no way to tell at a glance which sessions are alive without clicking. - **User control**: Users should be able to manage their own environment list. Right now there's no action of any kind available on these entries. - **Security (secondary)**: As noted in #28917, stale session links can linger with no way to invalidate them, which is a concern on shared machines. ### Alternative Solutions _No response_ ### Priority Medium - Would be very helpful ### Feature Category CLI commands and flags ### Use Case Example 1. Start a Remote Control session in the morning, work on it, close the terminal at lunch. 2. Start another one in the afternoon on a different project, close it at the end of the day. 3. Next day, repeat. 4. Within a week, claude.ai/code shows 10+ dead environments in the list with no way to remove them, making it hard to locate the one I'm currently using. ### Additional Context Related: [#28917](https://github.com/anthropics/claude-code/issues/28917) (focuses on security/link-invalidation after shutdown). This request overlaps but emphasizes the environment list UX at claude.ai/code specifically, and the case where a user has accumulated multiple stale entries from normal repeated use.", "url": "https://github.com/anthropics/claude-code/issues/50884", "createdAt": "2026-04-19T20:27:49Z", "updatedAt": "2026-08-13T13:13:34Z", "timestamp": "2026-08-13T13:13:34Z", "metrics": { "reactions": 28, "comments": 8 }, "labels": [ "enhancement", "area:claude-code-web", "area:cli" ], "author": "wolfomania", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/50884", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-4eae242b8d09" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Documentation-related issue with no assignee listed" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:53516", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Stable, documented schema for ~/.claude/projects//.jsonl line types", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement ## Context We are building a sibling VS Code / Cursor / Windsurf extension (`aims.dashboard`) that runs alongside the official `anthropic.claude-code` extension. The extension provides a four-pane operational shell over Claude Code: a persistent always-on chat pane that we drive ourselves through the Claude Agent SDK, and a per-task tab pane that is owned by the official extension. For the per-task pane we cannot use SDK in-process hooks, because we did not spawn those sessions; the official extension did. Our only viable observation channel for those sessions is to file-watch the append-only JSONL transcripts under `~/.claude/projects//.jsonl`. Direct inspection of `extension.js` v2.1.119 confirms there is no public VS Code API exported from the official extension, no `extensionDependencies` hook, no command surface for observing session state, and the IDE MCP bridge under `~/.claude/ide/.lock` exposes driver-side tools (manipulate the IDE) rather than observer-side events (watch what the CLI is doing). The JSONL transcript is the only durable, cross-process observation channel for sessions we did not spawn ourselves. Several community dashboards already depend on this surface (examples in the references section). We expect more to appear as VS Code 1.109's multi-agent positioning takes hold. ## What we observed A spot-check of current local transcripts on Claude Code v2.1.118 / v2.1.119 surfaces the following top-level `type` values in a single mid-length project session: ``` agent-name assistant attachment custom-title file-history-snapshot last-prompt permission-mode queue-operation system user ``` `type=system` carries a `subtype` field. The values we have observed are: ``` away_summary bridge_status compact_boundary local_command scheduled_task_fire stop_hook_summary turn_duration ``` When the CLI is launched with `--include-hook-events`, we additionally see `system/hook_callback` lines. Several of these (`agent-name`, `custom-title`, `queue-operation`, `local_command`, `scheduled_task_fire`, `pr-link`, `system/bridge_status`) are recent additions that did not appear in older transcripts and are not described in the public docs. We have no way to know whether new types are additive (safe) or whether existing types may be renamed or removed (breaking). ## Why I think this benefits Anthropic - **More durable third-party integrations.** A documented and stable schema lets the ecosystem of dashboards, statusline scripts, and observability tools track Claude Code releases without breaking on every upgrade. - **Reduced support load.** Tool-builders today reverse-engineer the schema from minified `extension.js` and a sample of live transcripts. A single documentation page absorbs the questions that currently end up on issues, Discord, and community blog posts. - **Aligns with VS Code 1.109 multi-agent direction.** The official editorial line (\"running Claude and Codex agents directly alongside Copilot is the future\") implies a richer ecosystem of co-resident extensions. A stable observation contract is a load-bearing piece of that ecosystem. - **Existing community dependence.** Several community dashboards already parse the format (`jspw/Claude-Code-Dashboard`, `nateherkai/token-dashboard`, `withLinda/claude-JSONL-browser`, `phuryn/claude-usage`, statusline scripts via `ccusage` and `ClaudeCodeStatusLine`). Documenting the contract recognises a surface the ecosystem is already treating as public. ### Proposed Solution We would like one or more of the following: 1. **Documented schema for each line type and `system.subtype` value.** A single page (e.g. under `code.claude.com/docs/en/`) listing each `type`/`subtype` and its required and optional fields. This need not be exhaustive; the core types (`user`, `assistant`, `system/*`, `attachment`, `permission-mode`) cover most observer use cases. 2. **A stability commitment.** A statement of the form \"additions are safe at any minor release; removals or renames are announced in the changelog one minor release ahead.\" Even a SemVer-style versioning of the transcript schema (separate from the CLI SemVer if necessary) would be enough for tool-builders to pin a known-good schema and detect drift. 3. **Changelog entry per minor release listing JSONL additions or changes.** The current changelog at `anthropics/claude-agent-sdk-typescript` and the Claude Code release notes do not mention JSONL line-type changes. A one-line note when a new `type` or `system.subtype` is introduced would let tool-builders update their parsers in step. ### Alternative Solutions **A public observation API.** If the schema is too volatile to commit to, an alternative is a public event surface -- either via the existing IDE MCP bridge (additional MCP tools whose role is observation, e.g. `mcp__ide__subscribeToolEvents`), via a published cross-extension API on the official VS Code extension (an `EventEmitter` returned from `activate()`), or via a Language Model Chat Participant interface that other extensions can subscribe to. Any of these would let us drop the file-watch path entirely. ### Priority Critical - Blocking my work ### Feature Category Developer tools/SDK ### Use Case Example ## Use case `aims.dashboard` provides a four-pane operational shell: - **Pane 1 (always-on CoS chat):** SDK-driven; we own these sessions and use the SDK's in-process hook surface (`SessionStart`, `PreToolUse`, `PostToolUse`, `Notification`, `Stop`, `PreCompact`). This pane is unaffected by JSONL schema changes. - **Pane 2 (per-task session tabs):** owned by the official extension via the URI handler `vscode://anthropic.claude-code/open?prompt=...&session=...`. We file-watch the JSONL to surface tool-call status, permission prompts, and session-end signals in a sidebar tray. This pane breaks silently when an unknown `type` or new required field appears. - **Pane 3 (status tray):** Supabase-backed projection of state across cockpits. Receives events from both Pane 1 (SDK callbacks) and Pane 2 (JSONL tail). - **Pane 4 (preview):** unaffected. The hybrid model lets us keep the polished UX of the official extension for the per-task pane (auto-accept diffs, native diff viewer, plan-mode markdown editing, sessions list, checkpoints) while still surfacing per-tool-call activity to operators in Pane 3 within a sub-second budget. If the JSONL schema is volatile, our Pane 2 observability degrades silently on every CLI upgrade. We currently mitigate this by pinning the CLI version via `pathToClaudeCodeExecutable` and writing a tolerant parser that ignores unknown `type` values, but a stability contract from Anthropic would let us decouple from the pinned version and keep up with upstream improvements automatically. ### Additional Context ## References Related issues we found while scoping this request (these illustrate the broader observation gap and are not duplicates of this request): - anthropics/claude-code#22968 -- high CPU/memory in long sessions; relevant because tools that observe CLI state often need to detect this condition. - anthropics/claude-code#34640 -- feature request for folder-scoped launches via URI handler. - anthropics/claude-code#36949 -- feature request for `claudeCode.workingDirectory` setting. - anthropics/claude-code#23119 -- JetBrains plugin discovery via the lock-file pattern (related observation surface). - anthropics/claude-code#24594 -- `--input-format stream-json` is undocumented; tool-builders depend on undocumented surfaces. - Datadog Security Labs CVE-2025-52882 -- IDE MCP bridge auth-token model. - Community dashboards depending on the JSONL: `jspw/Claude-Code-Dashboard`, `nateherkai/token-dashboard`, `withLinda/claude-JSONL-browser`, `phuryn/claude-usage`. - Statusline references that show how the JSON-on-stdin schema (already documented at `code.claude.com/docs/en/statusline`) became a community-stable contract -- a similar treatment of JSONL would be welcome. ## Environment - Claude Code CLI: v2.1.118 / v2.1.119 (Linux + macOS spot-checks) - Claude Agent SDK (TypeScript): @anthropic-ai/claude-agent-sdk >= 0.2.86 - VS Code 1.109+, Cursor 3.x, Windsurf - Operating systems: Linux (primary), macOS, Windows Happy to provide further sample transcripts or specific spot-check evidence if useful.", "url": "https://github.com/anthropics/claude-code/issues/53516", "createdAt": "2026-04-26T12:53:23Z", "updatedAt": "2026-08-13T02:35:00Z", "timestamp": "2026-08-13T02:35:00Z", "metrics": { "reactions": 5, "comments": 8 }, "labels": [ "enhancement", "area:ide", "area:docs" ], "author": "Mike-AugmentisLabs", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/53516", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-92f7b1866285" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:59408", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Ctrl+C and Ctrl+Shift+C silently clear prompt input with no confirmation or recovery", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When the prompt input buffer is non-empty, pressing either `Ctrl+C` or `Ctrl+Shift+C` silently discards the entire buffer. There is no confirmation, no echo to scrollback, no warning, and no way to recover what was typed. A single accidental keypress destroys arbitrarily large amounts of carefully composed work. Both keystrokes are strong muscle-memory copy shortcuts: - `Ctrl+C` is the universal copy shortcut in GUI applications. - `Ctrl+Shift+C` is the standard copy shortcut in many terminals (gnome-terminal, Konsole, Windows Terminal) and is also the browser devtools \"select an element\" shortcut. Users reach for one or the other reflexively, expecting a copy - or mistake which window has focus - and lose their work instead. ### What Should Happen? A non-empty input buffer must never be cleared without confirmation. Acceptable forms of confirmation: - An inline prompt (\"Discard N lines? y/N\"), or - A repeat-press confirmation: a single press shows a warning hint, only a second press within a short window commits the clear. After the clear, the action must be undoable via `Ctrl+Z`, and an onscreen hint at the moment of clearing must say so (e.g. \"Input cleared — press Ctrl+Z to restore\"). Without the hint the undo is undiscoverable. The two requirements pair: confirmation prevents accidents the user notices in time; undo plus hint catches the ones that slip through. ### Error Messages/Logs None. The clear is silent — no error, no warning, no echo of the discarded content. ### Steps to Reproduce 1. Open Claude Code in any standard terminal. 2. Type several lines into the prompt — enough that retyping would be costly. 3. With no text selected, press `Ctrl+C`. (Alternatively, `Ctrl+Shift+C`.) 4. Observe: the input buffer is cleared. Typed content is gone. No confirmation, no echo, no recovery. Reproduced in Windows Terminal, cmder, and the integrated terminal of a JetBrains IDE. ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.142 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information Related existing issues (different destructive targets, same class of bug — destructive keybinding with no confirmation): - #55590 - #52377", "url": "https://github.com/anthropics/claude-code/issues/59408", "createdAt": "2026-05-15T14:12:26Z", "updatedAt": "2026-08-13T06:14:26Z", "timestamp": "2026-08-13T06:14:26Z", "metrics": { "reactions": 10, "comments": 15 }, "labels": [ "bug", "platform:windows", "area:tui" ], "author": "pmg23", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/59408", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code.html#signal-2cba7c7a81b5" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:grafana/loki:issue:18760", "source": "github", "group": "observability", "project": "grafana/loki", "kind": "issue", "title": "Duplicate log lines can be introduced by automatic stream sharding", "text": "There may be other issues describing this but with a brief search I didn't find any. Loki currently has de-duplication logic which follows these rules: Lines are removed from results as duplicates when: * Are in the same stream * They have the exact same timestamp to the nanosecond * Have the exact same log content Not related to this issue directly but a different bug also exists #15425 where that logic also needs to be extended to compare if the structured metadata is the same or not. The problem here though is there are a number of situations where a log can be accepted by Loki but re-sent by a client and by the nature of how automatic stream sharding works, end up in a different stream. Auto stream sharding will add a label e.g. `__stream_shard__=1`, but when the log is resent it may end up in a different stream e.g. `__stream_shard__=5` This will result in these log lines not being de-duplicated properly in results.", "url": "https://github.com/grafana/loki/issues/18760", "createdAt": "2025-08-07T18:23:28Z", "updatedAt": "2026-08-13T08:26:15Z", "timestamp": "2026-08-13T08:26:15Z", "metrics": { "reactions": 13, "comments": 3 }, "labels": [ "type/bug" ], "author": "slim-bean", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/grafana/loki/issues/18760", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/loki.html#signal-21f08416b1d4" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:25453", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.527.31326 ### What subscription do you have? Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Codex Desktop repeatedly spawns short-lived powershell.exe children under the Codex.exe GUI process to run full-machine CIM/WMI scans over Win32_Process and Win32_PerfFormattedData_PerfProc_Process. In a fresh 30.05s measurement, I observed 23 PowerShell/pwsh processes, approximately 0.77/sec, consuming about 48.95 CPU-seconds total. Roughly 1.6 logical cores of sustained load from this recent change to how Codex monitors apps. Confirmed child command examples: powershell.exe -NoProfile -NonInteractive -Command \"... Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2\" powershell.exe -NoProfile -NonInteractive -Command \"... Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ... Get-CimInstance Win32_Process ... CommandLine,WorkingSetSize,...\" ### What steps can reproduce the bug? 019e7fe2-7262-7c50-bbbc-0a374d0db752 1. Run Codex Desktop on Windows. 2. Watch child processes under Codex.exe using Task Manager, System Informer, or Get-CimInstance Win32_Process. 3. When active, Codex.exe repeatedly spawns powershell.exe children running Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process. I do not yet have a deterministic trigger; the loop appears intermittent or state-dependent but happens while conversations are ongoing. ### What is the expected behavior? Codex Desktop should not spawn PowerShell repeatedly for full-machine process polling. Process tracking should be throttled, non-overlapping, scoped to Codex-owned process trees, or implemented through a persistent/native helper. ### Additional information This appears to be Codex Desktop app behavior, not the standalone Codex CLI. The parent process is the packaged Windows app Codex.exe, and the likely source is Desktop process-manager code in app.asar. This did not happen before the updates at the end of last week (~28th/29th).", "url": "https://github.com/openai/codex/issues/25453", "createdAt": "2026-05-31T21:43:42Z", "updatedAt": "2026-08-13T01:59:42Z", "timestamp": "2026-08-13T01:59:42Z", "metrics": { "reactions": 7, "comments": 25 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "jrf1001", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/25453", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-62555f5f3d02" }, { "tier": "triage-lead", "rankScore": 31, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:32297", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Built-in image generation repeatedly fails with network error after July 9 desktop update", "text": "### What version of the Codex App are you using? Current Codex Desktop build installed after the July 9, 2026 update. The exact About-dialog version was not available in this session. ### What subscription do you have? ChatGPT subscription using the normal Codex Desktop sign-in. ### What platform is your computer? macOS, Apple Silicon. ### What issue are you seeing? The built-in `image_gen` tool repeatedly fails while sending the generation request to the Codex image endpoint. The returned error is: ```text image generation failed: network error: error sending request for url (https://chatgpt.com/backend-api/codex/images/generations) ``` Ordinary text conversations and other Codex operations continue to work in the same session. This appears specific to the built-in image-generation route rather than a general loss of connectivity. Two separate image-generation attempts failed in the same way. Each request remained in a generating state for several minutes before returning the network error. ### What steps can reproduce the bug? 1. Open Codex Desktop. 2. Start a normal local task. 3. Ask Codex to use its built-in image generation tool to create a new image. 4. The request stays in the generating state for several minutes. 5. It eventually fails with the network error shown above. 6. Retry with a different, shorter prompt; the same failure occurs. ### What is the expected behavior? The built-in image generation request should complete and display or save the generated image. If the image service is unavailable, the app should fail promptly with a useful status instead of waiting several minutes. ### Additional information - Reproduced twice on July 11, 2026. - The prompts contained no reference images or unusual input. - Related recent reports after the same update window may include #32153, #32208, and #32038, although their visible failure modes are not identical. - No full diagnostic bundle is attached because it may contain unrelated local environment information. Additional narrowly scoped diagnostics can be provided if maintainers specify exactly which fields are needed.", "url": "https://github.com/openai/codex/issues/32297", "createdAt": "2026-07-11T00:35:21Z", "updatedAt": "2026-08-13T07:42:38Z", "timestamp": "2026-08-13T07:42:38Z", "metrics": { "reactions": 8, "comments": 23 }, "labels": [ "bug", "app", "connectivity", "imagen" ], "author": "woodenxyz", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/32297", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-e05b8d16b863" }, { "tier": "triage-lead", "rankScore": 30, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:35419", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "VS Code IDE context auto-disables and selected text is not attached in WSL2", "text": "### What version of the IDE extension are you using? 26.721.41059 ### What subscription do you have? Plus ### Which IDE are you using? VS Code ### What platform is your computer? 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64 GNU/Linux ### What issue are you seeing? Automatic IDE context initially appears enabled in the VS Code Codex composer, but the IDE context indicator disappears after a short time. Messages sent afterward do not include the active file or selected text. Running `/ide-context` or reloading VS Code does not permanently fix it. The extension log reports: [Composer] failed to fetch ide-context error={} The persisted `composer-auto-context-enabled` state is then changed to false. This reproduced after: - restarting WSL - restarting Windows - uninstalling and reinstalling the Codex extension in WSL ### Steps to reproduce 1. Open a repository using VS Code Remote - WSL. 2. Open a normal file-backed editor. 3. Select several lines. 4. Open the Codex sidebar. 5. Enable `/ide-context`. 6. Wait briefly or send a message. 7. Observe that the IDE context indicator disappears. 8. Ask Codex to identify the selected lines. 9. Observe that no active-file or selection context is attached. ### Expected behavior The IDE context setting should remain enabled, and each message should include the active file, selected text, and open tabs. ### Actual behavior IDE context discovery fails, the setting is automatically disabled, and selected text is omitted. ### Additional diagnosis The VS Code editor-side provider itself is working: - A standalone Codex CLI running in the same WSL workspace with `/ide on` successfully receives the active file and exact selected text. - Therefore VS Code selection tracking and the IDE IPC socket are healthy. Inspection of the clean-installed extension bundle showed that: - the non-Electron/VS Code path can request IDE context with an empty `workspaceRoot`; - a discovery error automatically persists the IDE-context preference as disabled; - the Webview `clientCoordination` path fails even though the editor-side provider can return the selection. A local workaround that preserves the enabled preference and retrieves the selection directly through the VS Code host bridge restores IDE context without changing VS Code, WSL, authentication, or network configuration. This appears related to, but distinct from: - https://github.com/openai/codex/issues/24514 ### What steps can reproduce the bug? Feedback ID: 019f9bde-3cda-77f2-8730-84e17b1237a0 ### What is the expected behavior? When IDE context is enabled, it should remain enabled and visible in the Codex composer. Each message should automatically include the current active file, selected text, and open tabs. Reloading VS Code should preserve this setting, and transient IDE discovery failures should not disable it. ### Additional information I reproduced the issue on a clean installation before applying any local changes. As a diagnostic workaround, I modified the installed extension locally to: 1. Always pass the actual workspace root when requesting IDE context, instead of passing an empty string on the VS Code/non-Electron path. 2. Prevent a transient IDE discovery failure from automatically persisting `composer-auto-context-enabled` as disabled. 3. Bypass the failing `clientCoordination.getIdeContext()` Webview RPC and retrieve the current IDE context directly through a VS Code host bridge backed by the extension's existing editor-selection provider. After reloading VS Code, the Codex message correctly contained: - the active file path; - the exact selected lines; - the list of open tabs. This confirms that VS Code selection tracking and the editor-side provider were working, while the failure was in the extension's Webview/context transport path. This is only a local diagnostic workaround, not a proposed production patch. It modifies generated extension bundle files and will be overwritten by an extension update or reinstall.", "url": "https://github.com/openai/codex/issues/35419", "createdAt": "2026-07-26T02:06:21Z", "updatedAt": "2026-08-12T21:35:20Z", "timestamp": "2026-08-12T21:35:20Z", "metrics": { "reactions": 11, "comments": 6 }, "labels": [ "bug", "windows-os", "extension" ], "author": "thisinnocence", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/35419", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-38ef63c9add9" }, { "tier": "triage-lead", "rankScore": 30, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:37398", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: opening any unloaded local chat waits ~5 seconds on owner discovery timeout", "text": "## Summary Codex Desktop waits about five seconds before displaying any unloaded local chat, even when the chat transcript is small. The actual thread read/resume completes in under 200 ms; the delay is a fixed owner-discovery timeout before fallback. ## Environment - ChatGPT/Codex Desktop: **26.803.41515** (build **6321**) - Bundled Codex: **0.147.0-alpha.6.5** - macOS **26.5.1**, arm64 ## Steps to reproduce 1. Launch the desktop app. 2. Open any unloaded local chat. 3. Observe that the content appears only after about five seconds. This reproduces with a small local transcript of 3,075,688 bytes, so it is not limited to large chats. ## Expected behavior The chat should appear as soon as `thread/read` and `thread/resume` complete. ## Actual behavior and timing Sanitized diagnostic timing from one reproduction: - `maybe_resume_started`: `2026-08-07T07:00:43.245Z` - `maybe_resume_owner_discovery_failed` with `timeout`: `2026-08-07T07:00:48.252Z` - Fixed wait before fallback: approximately **5,007 ms** - `thread/read` after fallback: **3 ms** - `thread/resume` after fallback: **182 ms** A background `avatarOverlay` renderer also emits `Conversation state not found`, although Pets were never enabled or opened by the user. The same owner-discovery timeout reproduces across multiple local threads. Deleting large chats and fully restarting the app did not eliminate the fixed delay. ## Privacy No raw logs, session transcript, browser tabs, or conversation content are attached.", "url": "https://github.com/openai/codex/issues/37398", "createdAt": "2026-08-07T07:23:11Z", "updatedAt": "2026-08-13T13:26:34Z", "timestamp": "2026-08-13T13:26:34Z", "metrics": { "reactions": 9, "comments": 15 }, "labels": [ "bug", "app", "session", "performance" ], "author": "galaxychi", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/37398", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-d948110331dc" }, { "tier": "triage-lead", "rankScore": 29, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:BerriAI/litellm:issue:26071", "source": "github", "group": "ai-infrastructure", "project": "BerriAI/litellm", "kind": "issue", "title": "[Feature]: Support adding skills to private repos with authentication (SSH key for local, GitHub access token for remote/private)", "text": "### Check for existing issues - [x] I have searched the existing issues and checked that my issue is not a duplicate. ### The Feature LiteLLM should support adding Claude skills (and similar AI skill plugin integrations) to private repositories. There should be a supported way to authenticate to a private repo, either via SSH key or a GitHub access token, so that skills can be used with code in private codebases. Currently, there is no clear documentation or programmatic support that covers how to authenticate and enable skills for private repos (local or GitHub-based) using the skills API. Feature Scope: - Allow registering or attaching Claude skills to private repositories - Support passing authentication, via either: - SSH private key for custom repos - GitHub access token for directly accessing private GitHub repos - Surface clear authentication errors and provide documentation for configuration - Expose this as part of the `add_skill` and store authentication info approproately - Provide inputs for auth in proxy UI If this is already possible, add documentation and a reference workflow for secure setup. ### Motivation, pitch Many organizations and developers use private repositories and want to leverage generative AI skills (like Claude's or similar) to automate, review code, or act as repo plugins. Without first-class authentication support, it is not possible to securely enable skills for internal or private codebases, blocking valuable use cases. ### What part of LiteLLM is this about? Proxy ### LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users? No ### Twitter / LinkedIn details https://www.linkedin.com/in/anengineerdude/", "url": "https://github.com/BerriAI/litellm/issues/26071", "createdAt": "2026-04-19T20:55:58Z", "updatedAt": "2026-08-12T13:50:57Z", "timestamp": "2026-08-12T13:50:57Z", "metrics": { "reactions": 13, "comments": 8 }, "labels": [ "enhancement", "proxy" ], "author": "anengineerdude", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/BerriAI/litellm/issues/26071", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/litellm.html#signal-ffa5cd19ec1e" }, { "tier": "triage-lead", "rankScore": 29, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:32870", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] claude.exe triggers Windows BSOD via Wof.sys during directory listing (NtQueryDirectoryFileEx)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? `claude.exe` (Claude Code CLI) triggers a Windows kernel BSOD (Blue Screen of Death) by performing heavy `NtQueryDirectoryFileEx` syscalls (standard directory listing). The crash occurs in `Wof.sys` (Windows Overlay Filter) at `WofPreDirectoryControlCallback+0x695` — a CFG (Control Flow Guard) indirect-call guard violation. **This is not an external Windows kernel bug in Wof.sys, but a Claude Code bug**, due to Claude Code's intensive directory scanning, no delay in the same instant makes it a reliable trigger. Filing here so Anthropic is aware that Claude Code can crash Windows systems with this specific Wof.sys version, as well as wsl hypervisor. ## Crash Statistics (all triggered by claude.exe) | Date | BSODs | Bugcheck codes | |------|-------|----------------| | 2026-03-06 | 7 | 0x139, 0x3B, 0x50, 0x10E, 0x1E, 0x14F | | 2026-03-09 | 1 | 0x139 | | 2026-03-10 | 5 | 0x139 (x2), 0x3B (x2), 0x1E (x1) | | 2026-03-11 | 1 | 0x50 | | **Total** | **14** | **4 distinct types at same Wof.sys +0x695 offset** | All March 9-11 crashes have identical call stack: ``` NtQueryDirectoryFileEx → FLTMGR → Wof!WofPreDirectoryControlCallback+0x695 → CFG guard violation ``` **4 manifestations of the same bug** — the corrupted indirect call target lands in different memory regions: 1. **0x139** — CFG guard catches invalid target before execution 2. **0x3B** (`c0000005`) — pointer escapes CFG, hits unmapped memory → access violation 3. **0x1E** (`c0000005`) — same access violation via different exception path 4. **0x3B** (`c000001d`) — pointer lands on non-code bytes → illegal instruction 5. **0x50** — pointer references invalid page in nonpaged pool ## Affected Configuration - **Wof.sys**: 10.0.26100.5074 (ships with Windows 11 25H2 build 26200) - **Compact OS**: Enabled increases crash frequency, but crashes also occur with CompactOS disabled - **WOF minifilter**: Attached at altitude 40700, intercepts every NTFS directory IRP ## Microsoft Bug Report Filed on Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i ## Potential Mitigation Could Claude Code reduce the frequency/intensity of `NtQueryDirectoryFileEx` calls, or batch directory listings differently? This wouldn't fix the kernel bug, but might reduce the trigger rate on affected systems. ### What Should Happen? Claude Code should be able to perform directory listings without triggering a Windows BSOD. On systems with Wof.sys 10.0.26100.5074, the high volume of `NtQueryDirectoryFileEx` calls from claude.exe reliably crashes the kernel. Ideally: 1. Claude Code could throttle or batch directory enumeration on Windows to reduce the frequency of `NtQueryDirectoryFileEx` calls 2. Or detect the vulnerable Wof.sys version and warn the user to disable Compact OS (`compact /CompactOS:never`) ### Error Messages/Logs ```shell WinDbg !analyze -v output (abbreviated): KERNEL_SECURITY_CHECK_FAILURE (139) Arg1: 000000000000000a — indirect call guard check detected invalid control transfer FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback+0x695 FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d} STACK_TEXT: nt!KeBugCheckEx nt!guard_icall_handler+0x1e nt!KscpCfgDispatchUserCallTargetEsSmep+0x11 Ntfs!FindNextIndexEntry2+0x675 Ntfs!NtfsContinueIndexEnumeration+0x10e Ntfs!NtfsQueryDirectory+0xd32 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe FLTMGR!FltPerformSynchronousIo+0x443 Wof!WofPreDirectoryControlCallback+0x695 <-- CRASH FLTMGR!FltpPerformPreCallbacksWorker+0x58f nt!NtQueryDirectoryFileEx+0xd8 PROCESS_NAME: claude.exe MODULE_NAME: Wof IMAGE_VERSION: 10.0.26100.5074 Second manifestation (0x3B at the same offset): SYSTEM_SERVICE_EXCEPTION (3b) ExceptionCode: c0000005 (ACCESS_VIOLATION) FAILURE_BUCKET_ID: AV_Wof!WofPreDirectoryControlCallback+0x695 FAILURE_ID_HASH: {3ae300a6-24ac-569b-3ce2-789a00065d56} ``` ### Steps to Reproduce 1. Run Windows 11 25H2 (build 26200) with Wof.sys 10.0.26100.5074 2. Optionally enable Compact OS: `compact /CompactOS:always` (increases frequency but not required) 3. Run `claude` in a large directory (e.g., a monorepo with many files/subdirectories) 4. Claude Code performs intensive directory listings via `NtQueryDirectoryFileEx` 5. System BSODs with bugcheck 0x139 (KERNEL_SECURITY_CHECK_FAILURE) or 0x3B (SYSTEM_SERVICE_EXCEPTION) **Workaround**: `compact /CompactOS:never` reduces frequency but does not eliminate the bug. **Environment**: - Windows 11 25H2 Build 26200.7922 - 192GB RAM, 32 cores, NVIDIA RTX 5000 Ada - 3.8 TB disk - Monorepo with ~100K files across nested directories ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.72 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information ## Minidumps & Diagnostics **Two ZIP archives** with all kernel minidumps and diagnostic outputs: 1. **[Original ZIP (Mar 9 dump)](https://drive.google.com/file/d/1KqVYJ6hMW5JCVPeh8Rccl4s6EC8SDVBJ/view?usp=sharing)** — 1x `.dmp` from 03-09 2. **[New ZIP (Mar 10-11 dumps)](https://drive.google.com/file/d/1KQ8COI5WB7B5EfMnOpFKSQ1OGMbrqsYI/view?usp=sharing)** — 5x `.dmp` files from 03-10 and 03-11 Contents: 6x `.dmp` files total, WinDbg analysis, system info, event logs, driver list, triage output. ## Hardware Tests Performed (all clean) - Windows Memory Diagnostic: PASSED - Disk scan: No corruption - SFC /scannow: No integrity violations - DISM /RestoreHealth: Clean - In-place upgrade, repair install from ISO: Completed (replaced all files except Wof.sys) ## Why This Is a Wof.sys Bug, Not Hardware 14 crashes at the **exact same instruction** (`WofPreDirectoryControlCallback+0x695`) across 6 days, producing 4 different exception types (0x139, 0x3B, 0x1E, 0x50) at the same offset. Random memory corruption wouldn't hit the same instruction deterministically. The 4 different bugcheck codes are expected — the corrupted indirect call target lands in different memory regions each time, producing different CPU exceptions. ## Microsoft Q&A Thread https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i", "url": "https://github.com/anthropics/claude-code/issues/32870", "createdAt": "2026-03-10T15:45:47Z", "updatedAt": "2026-08-13T14:57:24Z", "timestamp": "2026-08-13T14:57:24Z", "metrics": { "reactions": 1, "comments": 40 }, "labels": [ "bug", "has repro", "platform:windows", "external" ], "author": "VRDate", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/32870", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-acd7da98009d" }, { "tier": "triage-lead", "rankScore": 29, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:15723", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Background subprocesses/subagents do not wake the calling agent on completion", "text": "### What version of Codex CLI is running? codex-cli 0.116.0 ### What subscription do you have? API Key ### Which model were you using? gpt-5.3-codex medium ### What platform is your computer? Linux 6.8.0-101-generic x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? tmux ### What issue are you seeing? Long-running background sub-processes and sub-agents do not inform the calling agent when they complete. Instead the calling agent must either: 1. Block the message thread by continuously polling for a result; or 2. Wait for the user to request an update ### What steps can reproduce the bug? In interactive mode, prompt the agent with: ``` Use `exec_command` to run the following script in a background terminal: `sleep 15; echo \"print the whale emoji\"` ``` or ``` Run a subagent in the background with the following prompt: `wait for 15 seconds then respond with the whale emoji\"` ``` In both cases, the agent spins up the sub-task, responds to the user, and then does nothing after the sub-task returns. ### What is the expected behavior? Agents should be informed when long-running sub-processes return so they can take autonomous action. ### Additional information In other agent harnesses, watcher scripts can be used to automate agent actions. An agent can run a script in the background that polls an external endpoint without blocking the main interaction loop. When the script returns, the agent is able to respond autonomously without user intervention. Codex agents cannot implement this pattern because sub-processes do not appear to queue a message for the agent.", "url": "https://github.com/openai/codex/issues/15723", "createdAt": "2026-03-25T06:00:58Z", "updatedAt": "2026-08-13T06:01:26Z", "timestamp": "2026-08-13T06:01:26Z", "metrics": { "reactions": 8, "comments": 15 }, "labels": [ "bug", "subagent" ], "author": "zoox101", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/15723", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-67e2097469dd" }, { "tier": "triage-lead", "rankScore": 29, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:21803", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Feature request: Cross-device sync for Codex Projects and Chats", "text": "### What feature are you requesting? I would like Codex to support cross-device continuity for Projects and Chats when signed in with the same OpenAI account. For example, I use Codex across two Mac computers. Ideally, I could start a Codex Project or Chat on one Mac, then open Codex on another Mac with the same account and continue the same Project or Chat from where I left off. ### Why is this useful? Many developers regularly switch between a desktop and a laptop. Today, Codex sessions and project context feel tied to the local machine, which means switching devices requires manually recreating context, syncing notes, or relying on external workarounds. My ideal experience would be similar to ChatGPT conversation continuity: recent Codex Projects, Chats, task state, and high-level working context would be available across trusted devices. I understand that local filesystem paths, repositories, terminal state, and approval settings may need to remain device-specific. But it would still be very valuable to sync or restore: - Conversation history - Project metadata - Current task state - Recent working context - Associated repository information - Session summaries or checkpoints ### Possible implementation options A native account-level sync feature would be ideal. If full native sync is not currently planned, I would also be grateful for any official API, SDK, MCP integration, or supported import/export mechanism that would allow users to build this functionality themselves. For example, an official way to access, export, restore, or synchronize Codex sessions across trusted devices would make it possible to build a personal “session hub” or workflow manager around Codex. ### Related discussions / issues This request is related to, but more specifically focused on cross-device Codex continuity: - https://github.com/openai/codex/issues/5609 - https://github.com/openai/codex/discussions/14067 - https://github.com/openai/codex/issues/14722 ### Additional context Thank you for building Codex. It has been very helpful, and cross-device continuity would make it much smoother for users who regularly move between multiple computers.", "url": "https://github.com/openai/codex/issues/21803", "createdAt": "2026-05-08T19:02:12Z", "updatedAt": "2026-08-13T07:24:17Z", "timestamp": "2026-08-13T07:24:17Z", "metrics": { "reactions": 30, "comments": 3 }, "labels": [ "enhancement", "app", "session" ], "author": "HezLUO", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/21803", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-16db9c172c99" }, { "tier": "triage-lead", "rankScore": 29, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:34499", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Cannot create a local Work chat inside a ChatGPT Project (Windows Desktop App)", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.61943 (released July 21, 2026) ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Microsoft Windows NT 10.0.22631.0 x64 ### What issue are you seeing? When I try to create a Work chat inside an existing ChatGPT Project, I immediately receive errors such as: - \"Could not sync ChatGPT project context\" - \"Could not use this project for a local chat\" The Work chat is not created. ### What steps can reproduce the bug? Feedback ID: 019f83d4-3c04-78a2-a4ce-3f1ff9273b23 ### What is the expected behavior? A Work chat should be created inside the existing ChatGPT Project and retain access to the selected local folder. A Project should be able to contain one or more Work chats with access to local development folders. ### Additional information The problem occurs only when creating a local Work chat inside an existing Project. Environment: - Windows Desktop App - ChatGPT Plus account - Codex App version 26.715.61943 - Codex extension in VS Code works correctly - Local folder access works outside Projects Could you please confirm whether this is a known issue or a bug? Screenshots showing the error can be attached.", "url": "https://github.com/openai/codex/issues/34499", "createdAt": "2026-07-21T09:16:59Z", "updatedAt": "2026-08-13T02:34:23Z", "timestamp": "2026-08-13T02:34:23Z", "metrics": { "reactions": 7, "comments": 16 }, "labels": [ "bug", "windows-os", "app", "session" ], "author": "Paul722", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/34499", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-d033ee8c1831" }, { "tier": "triage-lead", "rankScore": 28, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:63903", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] autoMemoryEnabled=false does not suppress the ~11-16k memory preamble (re: closed #44829)", "text": "## Summary Setting `autoMemoryEnabled: false` in `~/.claude/settings.json` correctly disables auto-memory writes and stops Claude from attempting them, but the hardcoded memory preamble (instructional text + \\\"currently empty\\\" branch + formatting templates) still loads into the system prompt at session start. This was previously reported in #44829, which was auto-closed by the staleness bot on 2026-05-20 without Anthropic response. Re-filing with concrete measurement. ## Reproduction 1. `~/.claude/settings.json`: `{ \\\"autoMemoryEnabled\\\": false }` 2. Empty the memory directory: `rm ~/.claude/projects//memory/*.md` 3. Fully quit Claude Code app (`Cmd+Q`), relaunch. 4. Open a fresh session, run `/context` before sending any prompt. ## Measured impact (Claude Code 2.1.149, macOS) | Model | \\\"Memory files\\\" bucket | All other buckets | |---|---|---| | Sonnet 4.5 (200k window) | **11.3k tokens** | normal | | Opus 4.7 (1M window) | **16.2k tokens** | also inflated (+75% session overhead vs Sonnet) | Memory dir contents: **0 files, 0 bytes**. The entire bucket is preamble loaded from the binary. Binary inspection (`strings claude.app/Contents/MacOS/claude | grep -i memory`) surfaces 4 preamble templates: 27,303 / 22,477 / 4,482 / 105 chars. The smallest is the \\\"is currently empty. When you save new memories, they will appear here.\\\" branch — proof the preamble loads regardless of `autoMemoryEnabled` state. ## Impact - ~11k tokens/session wasted on Sonnet, ~16k on Opus, for users who have explicitly opted out of auto-memory. - For users with 5-tier learning systems (or any non-memory routing), this preamble actively pollutes context by suggesting routes Claude shouldn't take. - Scales with usage: at 100 sessions/week, ~1.1M tokens/week of preamble for an opted-out user. ## Requested behavior When `autoMemoryEnabled: false`: - Skip the memory preamble entirely (no instructional text, no \\\"currently empty\\\" branch, no format templates). - `/memory` slash command can still work via lazy-load when explicitly invoked. This is the fix #44829 originally requested — restating with measurement so it doesn't sit idle until the bot closes it again. ## Related - #44829 (closed-as-inactive 2026-05-20, NOT_PLANNED — no Anthropic response) - #56329 (open: \\\"Optionally disable memory\\\" — more general request) - #52488 (closed: \\\"decouple CLAUDE.md and MEMORY.md controls\\\")", "url": "https://github.com/anthropics/claude-code/issues/63903", "createdAt": "2026-05-30T08:43:13Z", "updatedAt": "2026-08-13T10:07:01Z", "timestamp": "2026-08-13T10:07:01Z", "metrics": { "reactions": 0, "comments": 43 }, "labels": [ "bug", "has repro", "platform:macos", "area:cost", "area:core", "memory" ], "author": "guillaume-paradise", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/63903", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-3488479a67c5" }, { "tier": "triage-lead", "rankScore": 28, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:astral-sh/uv:issue:12372", "source": "github", "group": "developer-infrastructure", "project": "astral-sh/uv", "kind": "issue", "title": "Have `uv sync` default to `--locked`", "text": "### Summary I was a little surprised/confused when migrating to `uv` that the default `uv sync` did not enforce that the project was synced exactly to `uv.lock` or else error if not. When reading through the docs, I found some references to `--frozen` - https://docs.astral.sh/uv/guides/integration/docker/#installing-a-project And then other references that used CI that didn't include it: - https://docs.astral.sh/uv/guides/integration/github/#syncing-and-running I saw `--locked` and it wasn't immediately obvious the distinction between it and the closely related `--frozen`. Part of this stemmed from the expectation that `uv sync` would only _sync_ and not change the project environment at all. I think I can see where the convenience motivation for `uv sync` working as it does could come from, but in my opinion, it would be a much safer default that `uv sync` tries to only install the environment as currently specifies, or errors if something is not correct. Whether it's a new developer, a Dockerfile, a CI configuration, I think the most desirable thing is to fail fast and give a useful error message rather than silently move on if the lock file is not up-to-date. Again, this is just for the `sync` command. The alternative is that if developers want to be safe about this, they need to duplicate `--locked` everywhere in their READMEs, Dockerfiles, CI configurations etc to be sure that something unexpected doesn't silently happen when the lock file is out of date.", "url": "https://github.com/astral-sh/uv/issues/12372", "createdAt": "2025-03-21T17:08:54Z", "updatedAt": "2026-08-13T15:22:46Z", "timestamp": "2026-08-13T15:22:46Z", "metrics": { "reactions": 13, "comments": 4 }, "labels": [ "enhancement" ], "author": "johnthagen", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/astral-sh/uv/issues/12372", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/developer-infrastructure/uv.html#signal-e8756a056c5d" }, { "tier": "triage-lead", "rankScore": 28, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:28726", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex IDE extension freezes code-server sidebar on desktop Chromium browsers", "text": "## Summary Codex IDE extension freezes code-server when opening the Codex sidebar on desktop Chromium-based browsers. The same code-server instance works normally without the Codex extension, and Android Samsung Internet can use the Codex sidebar much more reliably. ## Environment - Server OS: Arch Linux - Server surface: code-server - code-server version: 4.123.0, VS Code base 1.123.0 - Codex IDE extension version tested in code-server: `openai.chatgpt-26.602.71036-linux-x64` - Affected clients: - Arch Linux Chromium / Chrome / Edge-family Chromium browser - Windows Edge / Chrome-family Chromium browser - Less affected / working client: - Android Samsung Internet connecting to the same code-server instance ## Symptoms - With the Codex extension installed, opening the Codex sidebar freezes the code-server browser UI. - The freeze happens before opening a specific thread, during sidebar / Codex home / thread list visualization. - The UI appears usable for a few seconds, then freezes after the sidebar is opened. - Removing the Codex extension makes code-server work normally. - Using a mobile Android user agent in desktop Chromium did not avoid the freeze. ## Timeline - The issue started suddenly within the last week. - Arch Linux and code-server were updated after the first freeze, but the freeze persisted. - This makes the code-server update less likely to be the original trigger. ## Reproduction Steps 1. Run code-server on Arch Linux. 2. Connect from a desktop Chromium-based browser. 3. Install / enable the Codex IDE extension. 4. Open the Codex sidebar. 5. Observe the browser / code-server UI freezing during sidebar initialization. ## Diagnostics Performed - Removed Codex extension: freeze disappeared. - Tested desktop Chromium with mobile-sized window, disabled browser extensions, and Android Samsung Internet user agent: freeze still reproduced. - Tested Android Samsung Internet against the same code-server server: Codex sidebar worked much more reliably. - Isolated Codex home for code-server: - Used separate `CODEX_HOME=/home/smoke_nb_sv/.codex-code-server`. - Copied only auth/config/installation id. - Large session files and old session index were excluded. - Quarantined large session files: - Original `~/.codex/sessions` had about 211 MB total, largest file about 133 MB. - Moving large and old session files out did not fix the freeze. - Disabled plugin-related features for code-server's Codex app-server: - Launched app-server through a wrapper with: - `--disable plugins` - `--disable remote_plugin` - `--disable plugin_sharing` - Freeze still reproduced. - Disabled Codex Chat Session Item Provider registration in the extension bundle as a diagnostic patch. - Freeze still reproduced. - Dropped noisy IPC broadcasts in the extension bundle as a diagnostic patch: - `thread-stream-state-changed` - `thread-read-state-changed` - `thread-queued-followups-changed` - `query-cache-invalidate` - This reduced the earlier broadcast warning flood, but the freeze remained. - Disabled/replaced the recent thread list calculation in the webview bundle with an empty list as a diagnostic patch. - Freeze still reproduced. ## Logs / Observations Earlier logs repeatedly showed: ```text [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed Ignoring ipc-broadcast expectedVersion=6 method=thread-stream-state-changed ... version=7 ``` After broadcast-drop diagnostics, that warning flood was reduced, but the freeze persisted. Later `remoteexthost.log` showed workspace storage lock conflicts and multiple extension hosts: ```text EEXIST: file already exists, open '/home/.../.local/share/code-server/User/workspaceStorage/.../vscode.lock' Lock ... Could not acquire lock, checking if the file is stale. Lock ... The lock does not look stale, giving up. ``` During repeated reload/freeze tests, multiple code-server extensionHost processes and multiple Codex app-server processes accumulated. Several stale `workspaceStorage/*/vscode.lock` files pointed to dead extensionHost PIDs and had to be removed manually. ## Current Hypothesis This looks like a new compatibility issue in the combination of: - code-server - desktop Chromium-based browsers - Codex IDE extension webview/sidebar initialization - Codex app-server / IPC / VS Code ChatSession initialization - possibly workspaceStorage lock / repeated extensionHost startup behavior It does not appear to be only a large local session-history issue, because isolating `CODEX_HOME` and removing large sessions did not fix it. It does not appear to be only plugin/remote-plugin sync, because disabling those app-server features did not fix it. It does not appear to be only the recent thread list data, because forcing the recent thread list calculation to return an empty list did not fix it. The Android Samsung Internet result is notable: the same code-server UI and server worked much better there, while desktop Chromium browsers on Linux/Windows froze. ## Request Please investigate Codex IDE extension compatibility with code-server, especially: - Sidebar/webview initialization on desktop Chromium clients - ChatSession provider activation in VS Code-compatible web environments - Codex app-server IPC broadcast handling in code-server - Behavior when multiple extensionHost processes / workspaceStorage locks are created after reloads/freezes - Whether `thread-stream-state-changed` and related events can cause main-thread blocking or repeated webview work in code-server ## Notes The local extension bundle was modified for diagnostics only, with backups retained. The issue reproduced before those patches were applied.", "url": "https://github.com/openai/codex/issues/28726", "createdAt": "2026-06-17T13:05:10Z", "updatedAt": "2026-08-13T13:39:34Z", "timestamp": "2026-08-13T13:39:34Z", "metrics": { "reactions": 5, "comments": 22 }, "labels": [ "bug", "extension", "app-server", "performance" ], "author": "SMOKE-19", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/28726", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-dbf1fe5cf092" }, { "tier": "triage-lead", "rankScore": 28, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:35259", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop repeatedly re-enters the model during wait/status polling, consuming substantial credits", "text": "## Summary During intentional Ultra and multi-agent work, Codex Desktop repeatedly re-entered the model merely to wait for agents or poll terminal status. In a corrected reset-to-49%-usage window, model turns whose only tool action was wait/status polling accounted for **19.8% of raw local token volume**. Ultra and multi-agent use were intentional. The suspected defect is not normal agent fan-out; it is repeated model inference during quiet coordination and process-wait intervals, often at 30- or 60-second cadence. Related reports exist, but this report adds current-build evidence, replay-safe accounting, a full usage-cycle window, tool-level decomposition, a representative long-running trace, and a public-rate-card estimate. ## Environment - ChatGPT Pro - macOS on Apple silicon - Codex Desktop 26.721.31836 (build 5828) - Incident runtime: codex-cli 0.146.0-alpha.3.1 - Mostly GPT-5.6 Sol ## What issue are you seeing? Long-running multi-agent tasks can generate hundreds of distinct model turns that do no substantive work beyond calling one of these tools: - `wait_agent` - `list_agents` - `write_stdin` - generic `wait` Each polling interval appears to re-enter the model, ingest a large cached conversation prefix, and then make another wait/status call. This can continue for hours while delegated work or a terminal process is still running. ## Corrected local evidence I analyzed local rollout telemetry from one complete weekly reset window, from the reset through the first observed 49% usage state. The parser: - excludes copied parent-history prefixes in child rollouts; - starts each child at its live `task_started` boundary; - ignores unchanged cumulative token snapshots; and - counts only genuine per-turn token deltas. Corrected window: - 10,586 genuine model turns - 1,382,757,012 raw local tokens - 43,668,351 uncached input tokens - 1,335,723,264 cached input tokens - 3,365,397 output tokens - 96.83% cached-input share - 94,241 copied-prefix token records excluded - 404 duplicate token snapshots excluded Tool-only wait/status turns: | Tool group | Turns | Raw local tokens | Uncached input | Cached input | Output | Share of all raw | |---|---:|---:|---:|---:|---:|---:| | `wait_agent` / `list_agents` only | 985 | 142,137,652 | 2,654,345 | 139,365,376 | 117,931 | 10.3% | | `write_stdin` / `wait` only | 983 | 131,423,068 | 1,319,437 | 130,028,544 | 75,087 | 9.5% | | Combined | 1,968 | 273,560,720 | 3,973,782 | 269,393,920 | 193,018 | **19.8%** | Using the current public GPT-5.6 Sol rate card, the combined wait/status subset corresponds to an estimated **3,948 credits**. This is a rate-card estimate from local telemetry, not a claim about the private subscription billing ledger. ## Representative long-running trace One child task ran for about 10 hours 55 minutes and contained: - 1,417 genuine model turns - 254 `wait_agent` calls - 31 `list_agents` calls - 316 `write_stdin` calls - 12 generic `wait` calls - 613 combined wait/status-only turns - about 93.17 million raw local tokens attributable to those wait/status turns The wait/status subset was about 45% of that child task's genuine raw token volume. Most agent waits requested only 30 or 60 seconds before another model-mediated poll. ## Steps to reproduce 1. Start an Ultra task that delegates a genuinely long-running child task. 2. Let the child run for at least 30-60 minutes while the parent or another child coordinates it. 3. Observe repeated `wait_agent`, `list_agents`, `write_stdin`, or generic `wait` calls during otherwise quiet intervals. 4. Inspect per-turn local token deltas, excluding copied child-history prefixes and unchanged cumulative snapshots. 5. Note that status-only polling repeatedly creates distinct model turns and reprocesses a large cached context. ## Expected behavior Waiting for an agent or terminal process should be event-driven, or handled by the harness without repeatedly invoking the model. The model should wake when: - the child or process produces meaningful new output; - the child completes or requires attention; - the user sends new input; or - a deliberately bounded, low-frequency checkpoint is required. ## Actual behavior Quiet wait intervals repeatedly invoke the model so it can issue another polling tool call. Large cached prefixes are charged through the public credit model even though the turns produce almost no substantive user-facing work. ## Why this is not ordinary Ultra fan-out Ultra and explicit multi-agent delegation were intentional, and their extra cost is expected. The anomalous subset here is narrower: nearly one-fifth of corrected raw token volume came from turns whose only action was waiting or checking status. The same corrected window attributed 68.1% of raw volume to Ultra and 58.7% to subagents. Those figures describe the chosen workload. This issue concerns the avoidable model-mediated polling inside that workload. ## Evidence boundary - These figures come from local rollout telemetry, not OpenAI's internal billing ledger. - Raw local token volume is not the same as subscription usage. - The credit figure is an estimate using the published model rate card. - Copied historical token records were explicitly excluded and are not claimed as billing events. - I found no evidence here of a silent quota reduction. - No private prompts, task identifiers, repository names, local paths, account details, or transcript content are included. ## Related reports - #34468 — parent chat polls child agents every minute - #33276 — wait-for-agents loop drained quota - #35108 — nested wait-agent polling - #13733 — terminal polling - #18394 — default wait timeout - #34361 — replay attribution work ## Suggested fix direction - Make agent and terminal waits event-driven inside the harness. - Avoid a fresh model call when no meaningful state has changed. - Coalesce repeated status checks and apply backoff for long-running work. - Surface wait/polling usage separately in diagnostics. - Add regression coverage asserting that unchanged wait state does not create repeated billable model turns.", "url": "https://github.com/openai/codex/issues/35259", "createdAt": "2026-07-24T23:11:07Z", "updatedAt": "2026-08-13T05:20:50Z", "timestamp": "2026-08-13T05:20:50Z", "metrics": { "reactions": 7, "comments": 13 }, "labels": [ "bug", "rate-limits", "tool-calls", "app", "subagent" ], "author": "dimasyankauskas", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/35259", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-72024c25ca99" }, { "tier": "triage-lead", "rankScore": 28, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:ray-project/ray:issue:36415", "source": "github", "group": "ai-infrastructure", "project": "ray-project/ray", "kind": "issue", "title": "[core] Ray session conflicts with PyArrow+HDFS", "text": "### What happened + What you expected to happen Using PyArrow fs with HDFS works fine outside a ray session: ``` file_sys, file_path = pyarrow.fs.FileSystem.from_uri(hdfs_folder) file_infos = file_sys.get_file_info(pyarrow.fs.FileSelector(file_path, recursive=False)) ``` However, after `ray.init()`, the same code results in a segmentation fault: ``` 2023-06-14 01:27:37,622 INFO worker.py:1614 -- Started a local Ray instance. View the dashboard at http://127.0.0.1:8265 *** SIGSEGV received at time=1686731258 on cpu 0 *** PC: @ 0x7f99d20c5822 (unknown) (unknown) @ 0x7f996fa6ec85 208 absl::lts_20220623::WriteFailureInfo() @ 0x7f996fa6e9c8 64 absl::lts_20220623::AbslFailureSignalHandler() @ 0x7f99e81c6420 3408 (unknown) @ 0x7f99d1c2782e 48 (unknown) @ 0x7f99d1c2cc0f 240 (unknown) @ 0x7f99d2267a5f 144 (unknown) @ 0x7f99d2267d53 128 (unknown) @ 0x7f99d21092a0 64 (unknown) @ 0x7f99e81ba609 (unknown) start_thread [2023-06-14 01:27:38,591 E 9716 9731] logging.cc:361: *** SIGSEGV received at time=1686731258 on cpu 0 *** [2023-06-14 01:27:38,591 E 9716 9731] logging.cc:361: PC: @ 0x7f99d20c5822 (unknown) (unknown) [2023-06-14 01:27:38,591 E 9716 9731] logging.cc:361: @ 0x7f996fa6ec85 208 absl::lts_20220623::WriteFailureInfo() [2023-06-14 01:27:38,592 E 9716 9731] logging.cc:361: @ 0x7f996fa6e9e1 64 absl::lts_20220623::AbslFailureSignalHandler() [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99e81c6420 3408 (unknown) [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99d1c2782e 48 (unknown) [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99d1c2cc0f 240 (unknown) [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99d2267a5f 144 (unknown) [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99d2267d53 128 (unknown) [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99d21092a0 64 (unknown) [2023-06-14 01:27:38,593 E 9716 9731] logging.cc:361: @ 0x7f99e81ba609 (unknown) start_thread Fatal Python error: Segmentation fault # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f99e81c62ab, pid=9716, tid=0x00007f99baa56700 # # JRE version: OpenJDK Runtime Environment (8.0_362-b09) (build 1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09) # Java VM: OpenJDK 64-Bit Server VM (25.362-b09 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libpthread.so.0+0x142ab] raise+0xcb # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try \"ulimit -c unlimited\" before starting Java again # # An error report file with more information is saved as: # /ray/hs_err_pid9716.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # [failure_signal_handler.cc : 332] RAW: Signal 6 raised at PC=0x7f99e800300b while already in AbslFailureSignalHandler() *** SIGABRT received at time=1686731258 on cpu 0 *** PC: @ 0x7f99e800300b (unknown) raise @ 0x7f996fa6ec85 208 absl::lts_20220623::WriteFailureInfo() @ 0x7f996fa6e9c8 64 absl::lts_20220623::AbslFailureSignalHandler() @ 0x7f99e81c6420 3952 (unknown) @ 0x7f99d22c3843 240 (unknown) @ 0x7f99d211410e 352 JVM_handle_linux_signal @ 0x7f99d210731c 64 (unknown) @ 0x7f99e81c6420 10576 (unknown) @ 0x7f99d1c2782e 48 (unknown) @ 0x7f99d1c2cc0f 240 (unknown) @ 0x7f99d2267a5f 144 (unknown) @ 0x7f99d2267d53 128 (unknown) @ 0x7f99d21092a0 64 (unknown) @ 0x7f99e81ba609 (unknown) start_thread [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: *** SIGABRT received at time=1686731258 on cpu 0 *** [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: PC: @ 0x7f99e800300b (unknown) raise [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: @ 0x7f996fa6ec85 208 absl::lts_20220623::WriteFailureInfo() [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: @ 0x7f996fa6e9e1 64 absl::lts_20220623::AbslFailureSignalHandler() [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: @ 0x7f99e81c6420 3952 (unknown) [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: @ 0x7f99d22c3843 240 (unknown) [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: @ 0x7f99d211410e 352 JVM_handle_linux_signal [2023-06-14 01:27:38,618 E 9716 9731] logging.cc:361: @ 0x7f99d210731c 64 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99e81c6420 10576 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99d1c2782e 48 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99d1c2cc0f 240 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99d2267a5f 144 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99d2267d53 128 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99d21092a0 64 (unknown) [2023-06-14 01:27:38,619 E 9716 9731] logging.cc:361: @ 0x7f99e81ba609 (unknown) start_thread Fatal Python error: Aborted ``` Here is the log dump from java: [hs_err_pid9716.log](https://github.com/ray-project/ray/files/11743507/h5PTZ.log) The segfault occurs almost every time, but not always. It never occurs when ray is not initialized. Thus there is probably some interference between the ray session/global state and the java/pyarrow/hdfs connection. ### Versions / Dependencies Ray latest master, hadoop 3.2.4, java openjdk version \"1.8.0_362\" ### Reproduction script - Install HDFS with `./ci/env-install-hdfs.sh` - Create some directory in HDFS e.g. with `/opt/hadoop-3.2.4/bin/hdfs dfs -put /tmp/somewhere hdfs://[host]:8020/somewhere` - Run this script ``` def setup_hdfs(): \"\"\"Set env vars required by pyarrow to talk to hdfs correctly. Returns hostname and port needed for the hdfs uri.\"\"\" # the following file is written in `install-hdfs.sh`. with open(\"/tmp/hdfs_env\", \"r\") as f: for line in f.readlines(): line = line.rstrip(\"\\n\") tokens = line.split(\"=\", maxsplit=1) os.environ[tokens[0]] = tokens[1] import sys sys.path.insert(0, os.path.join(os.environ[\"HADOOP_HOME\"], \"bin\")) hostname = os.getenv(\"CONTAINER_ID\") port = os.getenv(\"HDFS_PORT\") return hostname, port import os import pyarrow import pyarrow.fs hostname, port = setup_hdfs() workspace_dir = f'hdfs://{hostname}:{port}/somewhere' # from ray.air._internal.remote_storage import upload_to_uri # upload_to_uri(\"/tmp/content\", workspace_dir) def get_list_of_files_under_hdfs_folder(hdfs_folder): file_sys, file_path = pyarrow.fs.FileSystem.from_uri(hdfs_folder) file_infos = file_sys.get_file_info(pyarrow.fs.FileSelector(file_path, recursive=False)) return file_infos print(f\"Success!, number of files in {workspace_dir}: {len(get_list_of_files_under_hdfs_folder(workspace_dir))}\") print(f\"Success!, number of files in {workspace_dir}: {len(get_list_of_files_under_hdfs_folder(workspace_dir))}\") print(\"initializing ray, and get number of files again.\") import ray ray.is_initialized() ray.init() print(\"After ray init\", len(get_list_of_files_under_hdfs_folder(workspace_dir))) ``` ### Issue Severity High: It blocks me from completing my task.", "url": "https://github.com/ray-project/ray/issues/36415", "createdAt": "2023-06-14T08:34:15Z", "updatedAt": "2026-08-13T02:47:35Z", "timestamp": "2026-08-13T02:47:35Z", "metrics": { "reactions": 4, "comments": 27 }, "labels": [ "bug", "P1", "core", "stability", "core-fundamentals" ], "author": "krfricke", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/ray-project/ray/issues/36415", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/ray.html#signal-a339f6056918" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:66020", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] macOS 26.5.1 kernel zone leak (data.kalloc.1024) from Claude Code CLI — claude.exe panics at ~20GB, leak rate scales 21→1027/sec with agent load", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Claude Code CLI triggers an unbounded kernel memory leak in macOS zone `data.kalloc.1024`. The leak is in kernel space, not Claude's userspace RSS. Zone count climbs from ~1,200 after reboot to ~21M elements (~20 GB), then the machine kernel panics. Leak rate scales with agent load (measured with `sudo zprint`): - ~21 elements/sec idle - ~103/sec moderate use - ~1,027/sec under heavy parallel agent work (shell tools, git, file I/O) At burst rate, time to panic is on the order of hours, not days. Four kernel panics in eight days (May 31 – Jun 6 2026), all with the same signature. This is not the MCP process fan-out pattern (#64366 / #45880): only 1 MCP server configured (obsidian). Panicked task is always `claude.exe`, not hundreds of `node` MCP children. Same mechanism as #44824 (closed duplicate, Apr 2026) — still reproducing on macOS 26.5.1 with quantified leak rates. ### What Should Happen? Claude Code sessions (including concurrent CLI sessions under load) should not cause unbounded kernel `kalloc.1024` growth or macOS kernel panics. Kernel zone usage should stay bounded; terminating Claude should stop further kernel leak growth (as reported in #44824 when the process is killed). ### Error Messages/Logs ```shell panic(cpu 6 caller 0xfffffe00392ab31c): zalloc[3]: zone map exhausted while allocating from zone [data.kalloc.1024], likely due to memory leak in zone [data.kalloc.1024] (20G, 21286288 elements allocated) @zalloc.c:4575 Panicked task: pid 14507: claude.exe Kernel Extensions in backtrace: com.apple.iokit.EndpointSecurity (1.0) com.apple.filesystems.apfs (2811.120.14) Live monitoring (same session, heavy load): now=06:18:37 zone=3364417 (~3.21 GB of the 20 GB ceiling) rate=1027/sec over 30s (delta 30834) at this rate, time to 21M ceiling: ~4h (285min) started this session at ~1,200; now 3364417 ``` ### Steps to Reproduce 1. Environment: macOS 26.5.1 (25F80), Mac17,2, 32 GB RAM, Claude Code 2.1.168, Terminal.app, 1 MCP server (obsidian). 2. Reboot Mac (clean zone: `data.kalloc.1024` ~1,200 elements). 3. Start 3–4 concurrent `claude` CLI sessions on a large monorepo (active agent work: Bash, git, ripgrep, file reads/writes). 4. In another terminal (optional), monitor zone every 30–60s: zprint 2>/dev/null | awk '$1==\"data.kalloc.1024\"{printf \"%s zone=%s (~%.2f GB)\\n\", strftime(\"%H:%M:%S\"), $7, $7*1024/1073741824}' 5. Observe monotonic zone growth; rate increases sharply under parallel agent + shell activity. 6. Expected failure: kernel panic when zone approaches ~21M elements (~20 GB), typically within hours under heavy load. Control: Kill all `claude` processes — growth should stop (per #44824). Reboot resets zone to ~1,200. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.168 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information Hardware: Mac17,2, 32 GB RAM Configured MCP servers: 1 (obsidian only) — rules out N×M MCP fan-out (#64366, #45880) as primary cause here. Related issues: - #44824 — same kalloc.1024 / claude.exe panic, closed duplicate, unresolved from reporter POV - #64366, #45880 — MCP multiplication; different mechanism on this setup Apple side: Kernel zone leak in data.kalloc.1024 with EndpointSecurity + APFS in backtrace; panic logs submitted / to be submitted via Feedback Assistant (UUID e.g. 67756C3A-BD42-4268-ABB8-E7A0DDA4F992). Workarounds tried: Spotlight Privacy on ~/.claude, ~/.grok, ~/.codex, worktrees; pruning ~44 GB agent worktrees — reduces indexing pressure but does not stop active kalloc.1024 growth under load. Request: Reopen or link tracking for #44824; investigate Claude Code's macOS file/sandbox/EndpointSecurity path on macOS 26; workarounds beyond \"reduce concurrent sessions\" (not viable for production deadlines).", "url": "https://github.com/anthropics/claude-code/issues/66020", "createdAt": "2026-06-07T10:49:22Z", "updatedAt": "2026-08-13T17:33:01Z", "timestamp": "2026-08-13T17:33:01Z", "metrics": { "reactions": 4, "comments": 23 }, "labels": [ "bug", "has repro", "platform:macos", "perf:memory" ], "author": "LeifErikH", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/66020", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-fdf530edf35f" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:79366", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Worktree sessions reuse an existing worktree directory from a previous session instead of creating a fresh one", "text": "## Environment - Claude Code 2.1.197 (desktop app session with worktree isolation) - macOS (Darwin 24.6.0) ## What happened Starting a new session (new task, worktree isolation enabled) placed the session inside an **existing** worktree directory that a previous session had created for an unrelated task, instead of creating a fresh worktree. A new branch was created for the new session, but it was checked out into the old worktree directory. The reflog of the reused worktree shows the history clearly (paths/branches lightly sanitised): ``` 072bd99 HEAD@{2026-07-20 09:14}: checkout: moving from to claude/ <- new session reuses dir cff5b74 HEAD@{2026-07-18 14:19}: checkout: moving from claude/ to HEAD cff5b74 HEAD@{2026-07-17 10:02}: checkout: moving from to claude/ cff5b74 HEAD@{2026-07-15 13:58}: commit: (previous task's commits) ``` So `.claude/worktrees/-/` (directory named after the *previous* task) is now hosting a branch for a completely different task. ## Expected Each new session/task with worktree isolation should get a **fresh** worktree directory named after its own task/branch, created off the default branch. ## Impact - The worktree directory name no longer matches the branch/task, which is confusing when several worktrees exist. - Leftover untracked/ignored files from the previous task can silently leak into the new task's context or PR. - This has happened repeatedly across sessions in the same repo (the user has had to add a standing instruction telling the model never to reuse existing worktrees, but the reuse happens at session setup, before the model can influence it). ## Possibly related observation In the same session, background subagents (Agent tool) appeared to default their working directory to the **main checkout** rather than the session's worktree — two subagents wrote files to `/docs/...` instead of `/.claude/worktrees//docs/...` and the files had to be moved manually. If subagent cwd inheritance is a separate issue I can file it separately.", "url": "https://github.com/anthropics/claude-code/issues/79366", "createdAt": "2026-07-20T09:33:40Z", "updatedAt": "2026-08-13T00:56:16Z", "timestamp": "2026-08-13T00:56:16Z", "metrics": { "reactions": 7, "comments": 11 }, "labels": [ "bug", "platform:macos", "area:agents" ], "author": "sandopolus", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/79366", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-20993a288687" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:23146", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex reports Chrome extension is not installed when connected in Brave", "text": "Codex reports Chrome extension is not installed when connected in Brave # Bug report: Codex reports Chrome extension is not installed even though the extension is connected in Brave ## Summary Codex reports that the browser extension is not installed, but the Codex Chrome Extension is installed and connected in Brave. The extension-backed browser connection works from Codex, but Codex's local detection appears to check only Google Chrome stable paths and Google Chrome profile data. ## Expected behavior Codex should recognize and use the connected Codex Chrome Extension when it is installed and connected in Brave, or the error message should clearly state that the check only supports Google Chrome stable. ## Actual behavior Codex reports that the browser extension is not installed. The extension popup in Brave shows: - Status: Connected - Extension: Codex - Version: v1.1.4 The Codex extension-backed browser runtime can also communicate with the extension and enumerate open tabs. ## Environment - OS: macOS 26.4.1 (Build 25E253) - Browser in use: Brave Browser 148.1.90.122 - Default browser bundle id: `com.brave.browser` - Google Chrome stable app: not installed at `/Applications/Google Chrome.app` - Brave app: installed at `/Applications/Brave Browser.app` - Codex Chrome Extension ID: `hehggadaopoacecdllhhajmbjkdcmajg` - Codex Chrome Extension version in Brave profile: `1.1.4_0` - Codex Chrome plugin cache path observed: `chrome@openai-bundled` version `0.1.7` ## Diagnostics ### Extension-backed connection works Using the Codex Chrome plugin browser runtime: ```json { \"connection\": { \"ok\": true, \"openTabCount\": 73, \"browserType\": \"extension\" } } ``` No tab URLs are included here for privacy; the important part is that the extension connection succeeds. ### Local detector looks for Google Chrome stable The Chrome DevTools MCP check failed with: ```text Could not find Google Chrome executable for channel 'stable' at: - /Applications/Google Chrome.app/Contents/MacOS/Google Chrome. ``` ### Codex helper script outputs `scripts/chrome-is-running.js --json`: ```json { \"platform\": \"darwin\", \"running\": false, \"processes\": [] } ``` `scripts/installed-browsers.js --json`: ```json { \"platform\": \"darwin\", \"default_browser\": { \"source\": \"LaunchServices\", \"schemes\": { \"https\": { \"scheme\": \"https\", \"bundle_id\": \"com.brave.browser\", \"name\": null, \"path\": null, \"version\": null }, \"http\": { \"scheme\": \"http\", \"bundle_id\": \"com.brave.browser\", \"name\": null, \"path\": null, \"version\": null } } }, \"installed_browsers\": [] } ``` `scripts/check-extension-installed.js --json`: ```text Could not find a Chrome profile directory with Preferences in ~/Library/Application Support/Google/Chrome. ``` Exit code: `3` `scripts/check-native-host-manifest.js --json`: ```json { \"manifestPath\": \"~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json\", \"expectedHostName\": \"com.openai.codexextension\", \"actualHostName\": \"com.openai.codexextension\", \"expectedExtensionId\": \"hehggadaopoacecdllhhajmbjkdcmajg\", \"expectedOrigin\": \"chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/\", \"allowedOrigins\": [ \"chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/\" ], \"exists\": true, \"nameMatches\": true, \"hasExpectedOrigin\": true, \"registryMatchesManifestPath\": true, \"correct\": true, \"problem\": null } ``` ## Additional local observations Brave has profile preferences at: ```text ~/Library/Application Support/BraveSoftware/Brave-Browser/Profile 1/Preferences ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Preferences ~/Library/Application Support/BraveSoftware/Brave-Browser/System Profile/Preferences ``` No Google Chrome profile preferences were found under: ```text ~/Library/Application Support/Google/Chrome ``` The Codex extension is present in the Brave default profile at: ```text ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Extensions/hehggadaopoacecdllhhajmbjkdcmajg/1.1.4_0 ``` ## Suspected cause The extension-backed runtime is able to connect to Brave, but the installation/health-check path appears to assume Google Chrome stable: - `/Applications/Google Chrome.app` - `~/Library/Application Support/Google/Chrome` Because this setup uses Brave only, the detector concludes that Chrome/the extension is missing even though the actual extension backend is connected and working. ## Suggested fix Either: 1. Support Chromium-family browsers such as Brave in the detector by checking the active connected browser/profile, or 2. If only Google Chrome stable is intended to be supported, change the user-facing error from \"extension not installed\" to a more specific message explaining that Google Chrome stable was not found or that Brave is unsupported.", "url": "https://github.com/openai/codex/issues/23146", "createdAt": "2026-05-17T12:18:14Z", "updatedAt": "2026-08-13T16:17:32Z", "timestamp": "2026-08-13T16:17:32Z", "metrics": { "reactions": 8, "comments": 4 }, "labels": [ "bug", "app", "browser" ], "author": "jarred-riggall", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/23146", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-8e725fe2f806" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:23930", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex app subagent cards can remain stuck/visible after close while close/readback reports no live agent", "text": "## Summary In the Codex app, completed or closed subagents can appear to remain visible/stuck in the UI for a long time even after the supported close/readback path reports that there is no live agent handle left. ## Component Codex app / Desktop on macOS. I do not know the exact app version from the UI at the time of filing. ## What happened A workflow used several subagents for bounded helper work. After the helpers completed, attempts to close them by exact returned agent IDs produced a mix of: - a completed previous status, - a running or pending previous status followed by successful disappearance from readback, - or not_found for handles that were already gone from the live route. Even after those close/readback results, the app UI could still make it look like subagents were present or stuck. In one child/subagent view, the UI showed a banner asking the parent to resume the sub-agent to continue the conversation, which suggests the child was closed, but the surrounding UI state still made it unclear whether a subagent was active, closed, or stale. ## Expected behavior After a subagent completes and is closed, the Codex app should make the lifecycle state unambiguous: - closed/completed subagent cards should update or disappear from active/open UI surfaces, - stale IDs should be shown as already closed rather than appearing stuck, - the parent thread should have a clear way to see that no live subagent remains, - and not_found after close/readback should not leave the user thinking an agent is still running or consuming an active slot. ## Actual behavior The live close/readback route can indicate that no live handle remains, while the UI still appears to show stale/open subagent state or a closed-child resume banner. This makes it hard to tell whether work is still running, whether slots are still occupied, or whether the UI is stale. ## Impact This is confusing during long-running work and makes it difficult to trust whether background/subagent work has actually stopped. It can lead to repeated close attempts and uncertainty about whether resources or subagent slots are still in use. ## Request Please clarify or fix the Codex app subagent lifecycle UI so the app reliably reflects completed/closed/stale states after subagent close/readback, especially when close returns not_found for an already-gone handle or when a child thread shows the parent-resume banner.", "url": "https://github.com/openai/codex/issues/23930", "createdAt": "2026-05-21T20:59:48Z", "updatedAt": "2026-08-13T06:21:30Z", "timestamp": "2026-08-13T06:21:30Z", "metrics": { "reactions": 4, "comments": 20 }, "labels": [ "bug", "app", "subagent" ], "author": "omarpinarecords", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/23930", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-1d92d1fd45af" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:26984", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP stdio servers leak pipe fds + orphan child processes → cumulative EMFILE (\"Too many open files\", os error 24)", "text": "# MCP stdio servers leak pipe fds + orphan child processes → cumulative EMFILE (\"Too many open files\", os error 24) ### What version of Codex CLI is running? codex-cli 0.137.0 (also reproduced symptom on long-running 0.12x sessions) ### What subscription do you have? Pro ### Which model were you using? n/a (process/transport bug, model-independent) ### What platform is your computer? Darwin 25.5.0 (macOS 26.5.1) arm64 ### What issue are you seeing? Long-running sessions that use stdio MCP servers slowly accumulate open file descriptors in the **codex parent process** until they hit the per-process soft limit (256 on a default macOS login shell), at which point every subsequent `open()`/`spawn()` fails with `Too many open files (os error 24)`. This is almost certainly the underlying **fd leak** behind the now-closed openai/codex#17806 (\"Repeat `Os { code: 24 }` crashes\"). That issue was closed via [#12216](), which only **hardened the panic** in `AbsolutePathBuf::parent()` so EMFILE no longer crashes the TUI — it did **not** address *why* fds are exhausted. The leak is still present. ## Evidence (live system) A single long-lived TUI session (`codex resume`, soft limit 256) sitting **3 fds under the ceiling**: ``` $ lsof -p | awk 'NR>1{print $5}' | sort | uniq -c | sort -rn 186 PIPE <-- the leak 38 REG (state_*.sqlite WAL/shm, rollout jsonl, logs_*.sqlite) 8 KQUEUE 7 unix 5 IPv4 ... 253 total (soft NOFILE = 256 -> next open() = EMFILE) ``` 186 anonymous PIPE fds for a session with \\~4–5 configured MCP servers (expected ≈3 pipes/server = \\~15). The excess maps almost 1:1 to **orphaned MCP child processes** that the codex parent still holds read pipes to. System-wide, orphaned stdio MCP servers far outnumber the live codex sessions that should own them: ``` $ pgrep -f slack-mcp-server | wc -l # 30 $ pgrep -f xcodebuildmcp | wc -l # 18 $ pgrep -f \"codex app-server\"| wc -l # 9 ``` These are spawned as `npm exec ` / `npx`, i.e. the actual server (`node`) is a **grandchild** under an `npm` wrapper. ## Root-cause analysis (code, codex-rs @ 8f1aad5) Cleanup of stdio MCP servers has three gaps that compound under the MCP **refresh/rebuild** churn. ### 1\\. Teardown is fire-and-forget — never awaits process exit `rmcp-client/src/stdio_server_launcher.rs` `LocalProcessTerminator::terminate` (unix): ```rust let should_escalate = terminate_process_group(pgid) /* killpg SIGTERM */ ...; if should_escalate { spawn(move || { // detached std::thread sleep(PROCESS_GROUP_TERM_GRACE_PERIOD /* 2s */); kill_process_group(pgid); // killpg SIGKILL }); } ``` `RmcpClient::shutdown` (`rmcp-client/src/rmcp_client.rs:678`) calls this and **returns immediately** — the SIGKILL lands ≥2 s later on a detached thread. Nothing awaits actual child exit or pipe EOF. If the runtime/parent is torn down (or the next refresh races) within that window, the SIGKILL thread can be lost, leaving the group alive. ### 2\\. Cancelled-startup path skips explicit terminate entirely On MCP refresh, `core/src/session/mcp.rs::refresh_mcp_servers_inner`: ```rust // :341 cancel old startup token guard.cancel(); // :344 build a brand-new manager — spawns the ENTIRE MCP server set again let (refreshed_manager, cancel_token) = McpConnectionManager::new(...).await; // :377 swap in let mut old_manager = std::mem::replace(&mut *manager, refreshed_manager); // :379 shut down the old one old_manager.shutdown().await; ``` For any old client still mid-handshake, `AsyncManagedClient::shutdown` (`codex-mcp/src/rmcp_client.rs:240`) resolves the shared startup future to `Err(Cancelled)`: ```rust match self.client().await { Ok(client) => client.client.shutdown().await, Err(StartupOutcomeError::Cancelled) => {} // <-- terminate() never called Err(error) => warn!(...), } ``` Cleanup then depends **entirely** on `Drop for StdioServerProcessHandleInner`, which only fires once the last `Arc` clone is dropped — and which itself uses the same fire-and-forget terminate from gap [#1](). The same full-set spawn-then-shutdown churn also runs in the ephemeral connector-discovery manager (`core/src/connectors.rs:273` … `:359`). ### 3\\. Group signalling misses `npm`/`npx` grandchildren Spawn uses bare `command.process_group(0)` (`stdio_server_launcher.rs:263`) and signals `pgid == direct-child PID`. The direct child is the `npm`/`npx` wrapper; the real server is `node`. When the wrapper exits (or the server reparents) the original group no longer covers `node`, so `killpg(SIGTERM/SIGKILL)` misses it → **orphaned node** (the 30/18 above). Note `utils/pty/src/process_group.rs` already has `detach_from_tty`/`setsid`-style helpers, but the stdio MCP launcher does not use a `wait`-and-verify reap. ### Net effect Each refresh/rebuild cycle spawns a fresh server set and tears down the old one **without awaiting death and without reliably reaping the** `npm` **grandchild**. Every orphan keeps its stdout/stderr **write** ends open, so the codex-side **read** pipe + the detached stderr-reader task (`stdio_server_launcher.rs:274`) never reach EOF and never close. Pipe fds in the codex parent grow **monotonically** until EMFILE. ## Suggested fixes 1. **Await actual exit on teardown.** Make `shutdown()`/Drop `waitpid`/`try_wait` the group after SIGTERM→SIGKILL instead of fire-and-forget, so pipes are closed deterministically. 2. **Terminate on the cancelled-startup arm.** In `AsyncManagedClient::shutdown`, call the process terminator on `Err(Cancelled)` rather than relying on `Drop`. 3. **Reap the whole group reliably.** Either spawn the server binary directly (resolve `npm exec`/`npx` to the real entrypoint) or `setsid` + track the session and kill+wait the session, not just the direct child's PID-as-PGID. 4. **(Hardening)** Bound the stderr-reader task to transport lifetime / close the read half on terminate so a lingering grandchild can't pin the pipe. ## Workaround for users Raise the per-process limit before launching (`ulimit -n 65536`, and/or `sudo launchctl limit maxfiles 65536 524288` for GUI-launched servers) and periodically kill orphaned `*-mcp-server` / `npx` processes. This only delays the leak. ### Related * openai/codex#17806 (closed) — same symptom; closed via panic-hardening only, leak not addressed * [#12216]() (closed) — EMFILE panic hardening in `AbsolutePathBuf::parent()` * openai/codex#25243 (open) — distinct root cause (Codex.app re-exec storm vs `syspolicyd`), not MCP", "url": "https://github.com/openai/codex/issues/26984", "createdAt": "2026-06-08T11:10:00Z", "updatedAt": "2026-08-13T12:03:51Z", "timestamp": "2026-08-13T12:03:51Z", "metrics": { "reactions": 4, "comments": 20 }, "labels": [ "bug", "mcp", "CLI" ], "author": "jacobcxdev", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/26984", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-a5d32f3fd12a" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:28864", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add shortcuts to edit or remove specific queued follow-up inputs in the TUI", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? When Codex is working, users can queue follow-up inputs before the current turn finishes. This is useful, but the queue is currently hard to manage once more than one follow-up has been added. The main issue is that queued messages are visible, but they are not directly actionable by position. If I queue several follow-ups and then notice that the second one is wrong, outdated, duplicated, or no longer relevant, I need a faster way to fix that exact item without interrupting the current turn or reshuffling the queue manually. This matters during long-running agent sessions because users often think ahead while Codex is still running. The queue becomes a lightweight plan for the next few interactions, so mistakes in the queue can easily send the agent down the wrong path. ## Feature Request Add numbered controls for queued follow-up inputs: * Display queued follow-ups with stable numbers. * Use `Option/Alt + number` to edit a specific queued message. * Use `Option/Alt + Shift + number` to remove a specific queued message. * Preserve the original queue position when an edited message is submitted back into the queue. * Keep the existing “edit latest queued message” shortcut as a fallback. * Pause queue running while editing queue. For example: * `Option + 2` restores the second queued follow-up into the composer for editing. * `Option + Shift + 2` removes the second queued follow-up from the queue. * `Option + 0` can target the tenth queued item if supported. ## Why This Should Be Implemented Queued follow-ups are already a strong workflow feature, but without direct queue management they become fragile once the queue contains multiple items. Users need to be able to correct the queue without stopping the current agent turn. This would improve the TUI in a few concrete ways: * Reduces accidental submissions of stale or incorrect follow-ups. * Makes queued input safer to use during long-running tasks. * Lets users manage future instructions without interrupting the agent. * Matches the visible UI model: if queued items are shown as a list, numbered shortcuts make them directly addressable. * Keeps the interaction keyboard-native and fast, which fits the terminal UI. * Avoids adding modal UI or mouse-dependent behavior. This is especially useful for users who actively steer Codex during long tasks, where queued follow-ups may include corrections, next steps, or additional constraints. Being able to edit or remove a specific queued item makes the queue feel intentional rather than append-only. ## Existing Implementation I implemented this functionality in my own Codex fork and have been using it successfully during long-running agent sessions. Implementation: [Commit 31bf78a0ba3c17651f812fae03461b98de3c77df](https://github.com/0xBRM/codex/commit/31bf78a0ba3c17651f812fae03461b98de3c77df?utm_source=chatgpt.com) Let me open the PR @tibo-openai :] ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/28864", "createdAt": "2026-06-18T06:08:19Z", "updatedAt": "2026-08-13T17:33:30Z", "timestamp": "2026-08-13T17:33:30Z", "metrics": { "reactions": 12, "comments": 6 }, "labels": [ "enhancement", "TUI", "CLI" ], "author": "0xBRM", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/28864", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-37d7a835e42a" }, { "tier": "triage-lead", "rankScore": 27, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:33192", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows 10] DWM Composition handles accumulate after Codex tasks with tool calls", "text": "## Summary On Windows 10 22H2, I can reproduce persistent growth in DWM's `Composition` handle count after Codex tasks that make terminal tool calls. A no-tool task that replied only `OK` did not show the same growth. In one controlled five-call run, the `Composition` count increased by 22 and remained elevated throughout the 30-second period after the task finished. After about four days of normal Codex use, DWM had 22,770 `Composition` handles, compared with 817 after a DWM restart. At that point, dragging an ordinary window could lag by 10 to 20 seconds. Restarting only DWM cleared the accumulated state and immediately restored smooth window movement. In a separate control, every `ChatGPT.exe` and `codex.exe` process was absent for about 5 minutes 35 seconds. No comparable new growth was observed while Codex was closed, but the handles already held by DWM did not fall. So far, they have only been cleared by restarting DWM or Windows. I cannot yet tell whether the lifetime problem begins in the Codex UI, Electron, Chromium, DirectComposition, DWM, or the graphics driver. This report documents the repeatable trigger and the resource signature. ## Environment - Windows 10 22H2, build `19045.7417`, x64 - Codex MSIX `OpenAI.Codex_26.707.9981.0_x64` - Internal app version `26.707.72221`, build `5307` - Electron `42.1.0` - Chromium/ProductVersion `150.0.7871.115` - One internal display at `2400 x 1600`, 60 Hz; no external display - Intel Iris Xe Graphics and NVIDIA GeForce RTX 3050 Ti Laptop GPU - HAGS enabled (`HwSchMode=2`) - Variable refresh optimization enabled (`VRROptimizeEnable=1`) - MPO disabled (`OverlayTestMode=5`) I have seen the same general problem across several Codex desktop updates. The version above is the one used for the controlled captures below. ## Reproduction 1. Start from a low DWM handle count after signing in to Windows or restarting DWM. 2. Open Codex and create a new task. 3. Ask it to make several separate, read-only terminal calls, for example: ```powershell Get-Date Get-Location Get-Process -Id $PID | Select-Object Id, ProcessName, HandleCount git status --short Get-ChildItem -Name | Select-Object -First 3 ``` 4. Record the count and type of DWM handles before the task, while it runs, and for at least 30 seconds after it finishes. 5. Repeat the task a few times. It is not necessary to keep Codex in the foreground. 6. For comparison, create a new task that only replies `OK` and does not call any tools. **Expected:** After a task finishes and its status UI settles, DWM `Composition` handles should return close to their previous baseline. **Actual:** Tasks with several tool calls leave a small persistent net increase. Repeating these task cycles gradually builds a much larger DWM-side handle stock. ## Controlled results | Test | Workload | Persistent DWM handle change | `Composition` change | | --- | --- | ---: | ---: | | Plain text control | New task replied only `OK`; no tools | `+5` | `-1` | | Five terminal calls | Five separate read-only calls | `+10` | `+22` | | Idle long task view | Visible and idle for about 10 minutes | `+2` | Not sampled by type | | Idle short task view | Visible and idle for about 10 minutes | `0` | Not sampled by type | | Active task | Running for about 6 minutes | `+66` | Not sampled by type | | Active task, Codex minimized | Running in the background | `+55` | Not sampled by type | | Scheduled task | Natural unattended run | `+88` | Not sampled by type | The two controlled runs used 30-second medians before and after the task. The DWM PID remained unchanged. ## DirectComposition trace I captured the five-call test with the `Microsoft-Windows-DirectComposition` and Dwm-Core ETW providers. During the server-reported task interval, DirectComposition recorded four identical 12-resource creation batches for DWM channel `61`. None of those 48 resources had a matching release before the trace ended. An identical fifth batch appeared about 2.1 seconds before the server `startedAt` timestamp, which may reflect local task initialization, but I cannot prove that from this trace. Every batch had this resource type sequence: ```text 201, 195, 195, 32, 32, 79, 87, 39, 58, 39, 58, 30 ``` The resource handles were sequential and had `openShared=false`. This capture did not include the Dwm-Core channel-attribution keywords, so I cannot map channel `61` to a specific client PID. The same batch signature also appeared occasionally outside the task interval. I therefore treat this as a correlation clue rather than proof that channel `61` belongs to Codex. The capture used Dwm-Core keyword mask `0x21`. A follow-up trace should use `0x900021` so that it also records `PROCESS_ATTRIBUTION`, `CHANNEL_OPENED_FOR_PROCESS`, `CHANNEL_CLOSED_FOR_PROCESS`, and `COMMAND_PROCESSED_ONBEHALF`. The DirectComposition mask can remain `0x5F`. DWM kept the same PID throughout the run. There was no lock-screen transition. `Video.UI` emitted no DirectComposition create or release events during the task interval, and the `ShellExperienceHost` burst began only after completion, consistent with the completion notification. ## Related report The closest existing report I found is [#16374](https://github.com/openai/codex/issues/16374), which describes progressive Windows shell freezes associated with Codex. This may be part of the same broader problem. The additional evidence here is the DWM handle type, the no-tool control, and the DirectComposition capture. ## Package note The affected package is an Electron 42 and Chromium 150 application, not WebView2. I found task-status and sidebar lifecycle code in the packaged ASAR, but the production package has no source maps, so I could not map the observed resource lifetime to a specific source module. ## Evidence retained locally The most relevant sanitized results are included above. I have also kept the complete ETL, the two run summaries, before-and-after handle type diffs, and the extracted DirectComposition batches. I have not attached the raw ETL because it contains a wider process timeline.", "url": "https://github.com/openai/codex/issues/33192", "createdAt": "2026-07-14T23:37:42Z", "updatedAt": "2026-08-13T17:16:18Z", "timestamp": "2026-08-13T17:16:18Z", "metrics": { "reactions": 7, "comments": 9 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "J-ShuJie", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/33192", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-71e2d5cb813a" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:63930", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Prompt cache fully re-created after turns with many parallel tool calls (cache_read collapses to system+tools floor) — ~74% of cache writes wasted on Opus 4.8 / v2.1.15x", "text": "## Describe the bug Since ~v2.1.154 (coincident with the Opus 4.7 → 4.8 switch), the prompt cache is repeatedly invalidated mid-session in two distinct ways, causing the entire conversation to be re-cached from scratch over and over. Across four of my sessions, **74% of all `cache_creation` tokens were waste** — re-caching content that had been cached seconds earlier — for ~$42 of needless Opus cache-write spend in those four sessions alone. I reconstructed the real API calls from the session transcripts (collapsing assistant records by `requestId`) and read `cache_read_input_tokens` (cr) and `cache_creation_input_tokens` (cc) from `message.usage`. In a healthy session every call satisfies `cr[n] ≈ cr[n-1] + cc[n-1]` (the cache grows monotonically as a prefix; cc is just the new turn's delta). Two failure modes break this: ### Mode B — message-history cache invalidated (`cache_read` collapses to the system+tools floor) — primary, high cost On certain turns the *next* request's `cache_read` collapses to the size of the system+tools block only (~18.7k tokens), and `cache_creation` balloons to ≈ the **entire** message history. The full history is re-written to cache, then read straight back on the following turn. The system/tools prefix stays cached; only the message-history portion is lost. Evidence it's the whole history, not a normal delta: - prior context 222,540 tok; a healthy `cc` would be ~12,902; **actual `cc` = 216,643**, `cr` = 18,799 - another turn re-cached **232,372 tokens** that had been cached **70 seconds** earlier (healthy `cc` would be ~3,121) This has **more than one trigger** — parallel tool-calling is the most common but not the only one: **Trigger 1 — a preceding turn with many parallel `tool_use` blocks** (most common). Sharply discriminated across four sessions: | | preceding-turn parallel `tool_use` blocks | |---|---| | **floor-miss calls** (n=14) | mean **16.7**, median 13 (dist `[0,0,12,12,12,12,13,13,15,15,17,25,43,45]`) | | **healthy calls** (n=68) | mean **2.5**, median 2 (only one ever exceeded 8) | → 12 of 14 floor misses in those sessions immediately follow a turn with ≥12 parallel tool calls. **Possible second trigger (tentative — single, entangled observation).** In one session a floor miss occurred on a user turn ~206s after the prior turn, with no heavy parallel-tool turn preceding it (`cache_read` dropped from ~152k to the 18,706 floor, re-caching 139k). But that same turn also invoked `ToolSearch` (see Mode A), so it is not a clean isolated case — treat it as **unconfirmed**. The parallel-tool trigger above is the well-supported one. These misses occur well inside Claude Code's cache TTL (Claude Code requests the **1-hour / 60-minute extended TTL**, `cache_control: {ttl: \"1h\"}`). Observed miss gaps range from **28s to ~25 min — all < 60 min**, so none is TTL expiry. ### Mode A — full cache invalidation (`cache_read → 0`) after `ToolSearch` When `ToolSearch` materializes a deferred tool, the *next* request's `cache_read` drops to **0** — the whole prefix (system + tools + history) is re-created. 3 of 3 full misses in my data are `ToolSearch`-preceded. This is consistent with the materialized tool schema being added to the `tools` array, which sits at the front of the cached prefix. (A `deferred_tools_delta` injected as *message* content does **not** break the cache, so it's specifically the `tools`-array mutation.) Confirmed live in one session: invoking `ToolSearch` to materialize `WebFetch` made the next request's `cache_read` drop to 0, and **rewinding to before that turn — so the materialized tool was removed from the `tools` array — restored normal caching.** That both isolates the `tools`-array mutation as the cause and gives a practical workaround (avoid unnecessary tool materialization; rewind past it if it happens). ## Steps to reproduce In a long Opus 4.8 session (context > ~50k tokens), either: 1. **Mode B (parallel tools):** get the assistant to issue one turn with **≥12 parallel tool calls** (easy during codebase exploration — many `Bash`/`Read`/`Grep` at once). On the next request, `cache_read` drops to the system+tools floor and `cache_creation` ≈ the full history. 2. **Mode A (`ToolSearch`):** call `ToolSearch` to materialize a deferred tool. On the next request, `cache_read` drops to 0. (Rewinding to before that turn restores caching.) Inspect `~/.claude/projects//.jsonl`: group `type:\"assistant\"` records by `requestId`, read `message.usage.cache_read_input_tokens` / `cache_creation_input_tokens`, and compare consecutive API calls. ## Expected behavior Parallel tool calls and deferred-tool materialization should not invalidate the cached conversation prefix. `cache_read` should keep growing monotonically; `cache_creation` should only ever cover the genuinely new content of the latest turn. ## Actual behavior The cached prefix is abandoned and the entire conversation history (100k–260k tokens) is re-written to cache on the next turn after a many-parallel-tool turn (Mode B) or after `ToolSearch` (Mode A), then read back on the turn after that. This repeats every few turns, billing cache **writes** (1.25× input rate) instead of cache **reads** (0.1×). ## Likely cause (inference — `cache_control` is not logged in transcripts) **Mode B** keeps system+tools cached but loses the entire message history, which means the request retained the system/tools breakpoint but no `cache_control` breakpoint covered the conversation prefix that was demonstrably cached moments earlier. The likely cause: Claude Code's rolling message-history breakpoint not surviving a heavy turn — with the API's 4-breakpoint limit, a single 12–45-block turn likely pushes the rolling breakpoints entirely inside the newly-added (uncached) block group, abandoning the breakpoint that covered the older prefix. **Mode A** is more direct: materializing a deferred tool changes the `tools` array at the front of the prompt, invalidating the whole prefix cache (`cache_read → 0`). The fix most likely belongs in Claude Code's cache-breakpoint / tools-array handling — neither aggressive parallel tool-calling nor on-demand tool materialization should invalidate an otherwise-warm prefix. **Honest confound:** the CC version bump and the Opus 4.7 → 4.8 model switch happened together, and Opus 4.8 parallelizes tool calls far more (max 4–11/turn on 4.7 vs 43–45/turn on 4.8). But the *within-session* contrast controls for the model: inside one Opus-4.8 session, floor misses occur only after heavy turns and never after normal turns (same model both times), so the parallel-tool-block count is the causal trigger and the breakpoint handling is what fails to cope. ## Impact (4 sessions analyzed) - 17 cache-miss turns - 3,062,631 `cache_creation` tokens billed; **2,259,367 (74%) were waste** - ≈ **$42** wasted Opus cache-write spend across just these four sessions ## Environment - Claude Code version: **2.1.158** (also reproduced on 2.1.156; first seen at 2.1.154) - Model: **claude-opus-4-8** - OS: macOS 26.5 (build 25F71), Darwin 25.5.0 - Pre-regression control: ~1,750 API calls across 8 sessions on v2.1.140–2.1.153 with **claude-opus-4-7** showed only one ≥12-tool turn and zero floor misses. ## Notes / red herrings ruled out - Records with `cache_read=0, cache_creation=0, input=0` are `model:\"\"` (`stop_reason:\"stop_sequence\"`, output 0) — locally-generated interrupt/stop placeholders, not API calls. Excluded. - TTL expiry excluded: Claude Code requests the 1-hour / 60-minute extended cache TTL (`cache_control: {ttl: \"1h\"}`), and every observed miss gap (28s up to ~25 min) is well under 60 min — so no miss is explained by expiry.", "url": "https://github.com/anthropics/claude-code/issues/63930", "createdAt": "2026-05-30T10:53:46Z", "updatedAt": "2026-08-13T07:12:32Z", "timestamp": "2026-08-13T07:12:32Z", "metrics": { "reactions": 6, "comments": 9 }, "labels": [ "bug", "has repro", "platform:macos", "area:cost", "area:core", "api:anthropic" ], "author": "omrikais", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/63930", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-460e9635387a" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:20668", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop dictation fails in API-key auth mode because /backend-api/transcribe rejects API keys", "text": "### What version of the Codex App are you using (From \"About Codex\" dialog)? Version 26.429.30905 ### What subscription do you have? API key auth mode. ChatGPT login is not available for this account/device because phone verification cannot be completed. ### What platform is your computer? macOS / Darwin arm64 ### What issue are you seeing? Codex Desktop dictation fails when the app is authenticated with an OpenAI API key instead of a ChatGPT session. The user-facing error is the generic popup: ```text Unable to transcribe audio ``` This does not appear to be a microphone, input-volume, or network problem. The same machine can transcribe audio successfully through the public OpenAI audio transcription API using the configured API key. ### Steps to reproduce 1. Configure Codex Desktop to use API key auth. 2. Do not log in with ChatGPT session auth. 3. Open Codex Desktop on macOS. 4. Use dictation. 5. Dictation records audio but fails at transcription with `Unable to transcribe audio`. ### Observed behavior Local investigation showed that Codex Desktop posts dictation audio to the ChatGPT backend transcription route: ```text https://chatgpt.com/backend-api/transcribe ``` When that route is called using the configured OpenAI API key as bearer auth, the backend returns: ```json { \"error\": { \"message\": \"Unauthorized - Invalid access token\", \"code\": \"unauthorized_unknown\" }, \"status\": 401 } ``` The desktop UI collapses this into `Unable to transcribe audio`. ### Expected behavior Dictation should work for Codex Desktop users authenticated with API keys. ChatGPT login should not be required for basic dictation if the configured API key can already call OpenAI transcription APIs. ### Additional diagnostic evidence * macOS microphone permission for Codex was reset and re-granted. * Input volume was raised. * Microsoft Teams was fully quit to avoid microphone contention. * Direct network access to OpenAI APIs works. * Direct transcription against the public OpenAI audio transcription API succeeds with the same configured API key and `gpt-4o-mini-transcribe`. * A local workaround proxy was tested and confirmed working: * Codex Desktop sends its existing `/transcribe` multipart request to a local proxy. * The proxy injects `model=gpt-4o-mini-transcribe`. * The proxy forwards the request to `https://api.openai.com/v1/audio/transcriptions` using the configured API key. * Dictation works through that path. ### Suggested fix When Codex Desktop is in API-key auth mode, dictation should not send the OpenAI API key to `chatgpt.com/backend-api/transcribe` as if it were a ChatGPT backend access token. Suggested implementation options: 1. Route API-key-auth dictation directly to the public OpenAI audio transcription API (`/v1/audio/transcriptions`) and include a transcription model such as `gpt-4o-mini-transcribe`. 2. Or update the Codex/ChatGPT backend transcription route so it accepts Codex API-key auth mode correctly. ### Related issue This is related to openai/codex#18460, but this report narrows the likely root cause to API-key auth mode and includes a confirmed workaround path.", "url": "https://github.com/openai/codex/issues/20668", "createdAt": "2026-05-01T19:11:19Z", "updatedAt": "2026-08-13T09:02:09Z", "timestamp": "2026-08-13T09:02:09Z", "metrics": { "reactions": 8, "comments": 1 }, "labels": [ "bug", "auth", "app" ], "author": "someshfengade", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/20668", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-c4db9d3df3b5" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:23257", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Desktop compaction repeatedly embeds full image base64 in compacted checkpoints", "text": "### What version of the Codex App are you using? Codex Desktop on Windows: - App package: `OpenAI.Codex` - Version: `26.513.4821.0` - Package: `OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0` One affected rollout also recorded `cli_version: 0.119.0-alpha.28`. ### What platform is your computer? Windows x64. ### What issue are you seeing? Codex Desktop context compaction appears to repeatedly persist full inline image payloads inside `compacted` checkpoints, especially under `payload.replacement_history`. This makes long image-heavy threads keep growing even after automatic compaction. It also keeps the \"background information window\" / context usage high after compaction because the new compacted checkpoint can still contain the previous screenshots as base64 data. This looks related to #18629 and #22603, but this report is focused on the compaction layer: old `compacted` checkpoints and the latest `compacted.payload.replacement_history` repeatedly contain full image payloads instead of deduplicated references, lightweight placeholders, or a single latest compacted state. ### Local evidence I inspected local saved session JSONL files under the Codex home directory. I am intentionally omitting raw session contents, local paths, screenshots, cookies, thread text, and user data. #### Affected thread A Before repair: - Rollout JSONL size: `904.9 MB` - JSONL records: `40,378` - `compacted` records: `128` - Total bytes in `compacted` records: `770.9 MB` - Lines containing `data:image`: `315` - Total bytes in lines containing `data:image`: `822.5 MB` - Total `data:image` references: `1,787` - Latest `compacted` record size: `7.66 MB` - Latest `compacted` image refs: `15` - Latest `compacted.payload.replacement_history` length: `185` - Latest `compacted` visible string chars before image removal: about `7,954,167` - Latest `compacted` contained `15` image parts, plus a copied developer/plugin instruction block and an encrypted compaction blob. After a local schema-aware cleanup that kept the latest compacted checkpoint but removed inline image payloads and old duplicate compacted checkpoints: - `compacted` records: `1` - `data:image` refs: `0` - Latest `compacted` size: about `316 KB` - Latest `replacement_history` length remained `185` - Latest visible string chars after image removal: about `264,828` This is the important signal: the useful compacted text was much smaller than the full checkpoint because prior screenshots had been embedded into `replacement_history`. #### Affected thread B Another long thread repeatedly regenerated large compacted checkpoints: - One snapshot: rollout size `430 MB` - `compacted` records: `14` - Total bytes in compacted records: `117.6 MB` - Latest compacted record: `9.02 MB` - Latest compacted image refs: `24` - The Codex UI showed the background information window still around `54%` / `139k` tokens after compaction. - Local token-count records around the same time showed a post-compaction context total around `138,789 / 258,400`. After removing old compacted records and image payloads from the latest compacted checkpoint, the same thread became much smaller and the latest compacted record was under `100 KB`. However, if the thread continued running, Codex could generate new `compacted` records that reintroduced the same image payloads. ### Why this is a product-level problem Users can manually edit JSONL as a workaround, but it is risky. During local recovery, replacing large base64-looking strings too broadly can damage fields such as `encrypted_content`, which then causes resume/reconnect failures like: ```json { \"type\": \"error\", \"error\": { \"type\": \"invalid_request_error\", \"code\": \"invalid_encrypted_content\", \"message\": \"The encrypted content [...] could not be verified. Reason: Encrypted content could not be decrypted or parsed.\" }, \"status\": 400 } ``` So the durable fix should not require users to manually mutate saved session JSONL. Codex should compact or repair these sessions in a schema-aware way. ### Steps to reproduce 1. Use Codex Desktop in a long-running thread. 2. Use image-producing workflows repeatedly, such as screenshots, browser/computer-use images, image attachments, or other tool outputs that produce `input_image` / `data:image/...;base64,...` payloads. 3. Let Codex automatically compact the context several times. 4. Inspect the saved rollout JSONL. 5. Observe many `compacted` records and a latest `compacted.payload.replacement_history` that still contains full image payloads. 6. Continue the same thread; observe that automatic compaction can create more large compacted records rather than converging to a lightweight latest summary. ### Expected behavior Context compaction should not repeatedly embed full image bytes in `compacted.payload.replacement_history`. Instead, Codex should: - store image blobs out-of-line and keep only lightweight references in replayable history - deduplicate image payloads across records and compacted checkpoints - avoid retaining old compacted checkpoints once a newer compacted checkpoint supersedes them, or keep them out of the replay/hydration path - replace old image-heavy tool outputs with schema-valid lightweight placeholders during compaction - keep `encrypted_content` opaque or remove whole reasoning records in a schema-aware way during any repair path - provide a built-in \"repair / strip old media payloads\" action for already affected sessions ### Actual behavior `compacted` checkpoints can contain full inline image base64 payloads. Old compacted checkpoints accumulate, and the latest compacted checkpoint can still contain many prior screenshots in `replacement_history`. The thread remains slow/heavy after compaction and can continue to re-grow as new compacted checkpoints are written. ### Related issues - #18629 - #22603 - #11845 ### Privacy note I am not attaching the raw rollout JSONL because it contains private prompts, local paths, screenshots, and authentication material. The report above includes only sanitized structural measurements and field/type counts.", "url": "https://github.com/openai/codex/issues/23257", "createdAt": "2026-05-18T06:52:11Z", "updatedAt": "2026-08-13T07:09:57Z", "timestamp": "2026-08-13T07:09:57Z", "metrics": { "reactions": 5, "comments": 12 }, "labels": [ "bug", "context", "app", "session", "performance" ], "author": "SimpleZion", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/23257", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-e54891d7b5a5" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:27207", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "🩹 Restore archived chats access from the main Codex UI", "text": "### Summary Archived chats need to be accessible from the main Codex UI, not hidden under Settings → Archived chats. This appears to be a regression/removal: a user reports this was available from the main UI roughly two weeks ago, and now there is no obvious way to browse all archived chats from the main sidebar. If the user does not remember the chat name/title, search is not enough. ### Current behavior - Archived chats are effectively hidden in **Settings → Archived chats**. - The main sidebar does not provide an obvious **Archived** view/section. - Accidental archive feels like the chat disappeared. - Recovery is not discoverable unless the user already knows the settings location. ### Expected behavior Please restore/add archived chat access to the main UI: - Add an **Archived** section/view in the main sidebar. - Add a command-palette action such as **Show archived chats**. - Make search clearly include archived chats or provide an obvious archived filter/badge. - Show an **Undo archive** toast immediately after archiving. - Keep **Unarchive** available from the thread menu inside the archived-chat list. ### Why this matters Archive is a normal chat-management action, but recovery is currently too hidden. Users who accidentally archive a chat and do not know its title need a direct way to browse archived chats from the primary navigation. Environment: Codex Desktop on macOS.", "url": "https://github.com/openai/codex/issues/27207", "createdAt": "2026-06-09T16:19:22Z", "updatedAt": "2026-08-13T04:22:45Z", "timestamp": "2026-08-13T04:22:45Z", "metrics": { "reactions": 10, "comments": 8 }, "labels": [ "enhancement", "app", "session", "Papercuts 2026", "Papercuts: Source - Truffle Pig", "Papercuts: Type - Confusing" ], "author": "richa65-personal", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/27207", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-2d04b302cd06" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:33493", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Local compaction v2 retains unbounded input_image payloads, causing repeated auto-compaction", "text": "### What version of Codex is running? - Codex Desktop: `26.707.72221` - Embedded CLI: `codex-cli 0.144.2` - Platform: macOS 26.3 (Build 25D125), Apple Silicon - Model: `gpt-5.6-sol` ### What issue are you seeing? A long-running, image-heavy Codex Desktop thread enters a repeated auto-compaction cycle. After a compaction completes, the resulting history remains only slightly below the auto-compaction threshold. Even a short new question pushes it over the threshold again, so almost every new turn starts with another compaction. The compacted `replacement_history` keeps historical `input_image` items, including their full inline base64/data-URL payloads. Repeated compactions keep copying the same images into new compacted records. This produces two related effects: 1. The post-compaction prompt remains close to the context threshold, causing immediate re-compaction on subsequent turns. 2. The rollout JSONL grows rapidly because the same inline image payloads are persisted repeatedly. ### Local evidence From one affected thread: | Metric | Observed value | | --- | ---: | | Rollout JSONL size | approximately 4.16 GB | | Compaction records | 224 | | Images retained by the latest compacted replacement history | 92 | | Retained inline image/base64 characters | approximately 26.47 million | | Retained text characters | approximately 188,000 | | Effective context window reported for the session | 258,400 tokens | | Default auto-compaction threshold | approximately 244,800 tokens | | Prompt size immediately after compaction | approximately 236,000-237,000 tokens | The post-compaction history therefore has only about 8,000 tokens of headroom. A normal follow-up turn is sufficient to trigger compaction again. No full rollout is attached because it contains private prompts, paths, tool output, and images. I can provide additional redacted structural statistics if needed. ### Steps to reproduce 1. Use a long-running Codex Desktop thread containing multiple pasted screenshots or image inputs. 2. Continue until local/remote-v2 compaction occurs. 3. Inspect the newest `type: \"compacted\"` rollout record. 4. Confirm that `payload.replacement_history` retains user messages containing `input_image` data URLs. 5. Send a short follow-up question. 6. Observe another automatic compaction even though the previous compaction just completed. 7. Repeat several turns and observe the rollout file growing as image payloads are copied into additional compacted records. ### Expected behavior After compaction: - Retained multimodal history should be bounded by a realistic image/token/byte budget. - There should be enough hysteresis below the auto-compaction threshold for ordinary follow-up turns. - Old inline image payloads should not be duplicated indefinitely in every compacted rollout record. ### Actual behavior The current retained-message text budget treats images as zero text tokens and preserves them: ```rust ContentItem::InputImage { .. } => 0, ``` and later: ```rust ContentItem::InputImage { .. } => truncated_content.push(content_item), ``` The message-level `.max(1)` floor limits the number of image-only messages only very weakly. It does not account for image cost inside mixed text/image messages, image count, encoded byte size, or vision-token cost. Current source: - `codex-rs/core/src/compact_remote_v2.rs` - `message_text_token_count` - `truncate_message_text_to_token_budget` - `truncate_retained_messages_for_remote_compaction` ### Possible fix direction For active compacted history: 1. Give retained images a conservative estimated token cost, using the existing image-size/detail estimator where possible. 2. Add explicit caps for retained image count and/or encoded bytes. 3. Keep the newest images first and replace older images with a lightweight placeholder once the image budget is exhausted. 4. Add a regression test with many mixed text/image messages verifying that compacted history is bounded and a short next turn does not immediately trigger compaction again. For rollout persistence, consider storing images as content-addressed blobs or references rather than repeating full base64 strings. That storage concern may be better handled separately under the existing image-heavy rollout issue. ### Related issues - #24388: same underlying retained-`input_image` problem, closed after the compaction architecture changed; this report reproduces the behavior on the newer local compaction path. - #24550: large inline images in compacted `replacement_history` cause Responses WebSocket fallback. - #24676: image-heavy rollout JSONL causes Codex Desktop hangs and difficult session recovery. - #9601: images can poison context estimation after history mutation. I am willing to help with additional redacted diagnostics, test-case design, or an implementation if maintainers agree on the approach and invite a PR under the repository contribution policy.", "url": "https://github.com/openai/codex/issues/33493", "createdAt": "2026-07-16T04:01:14Z", "updatedAt": "2026-08-13T12:54:36Z", "timestamp": "2026-08-13T12:54:36Z", "metrics": { "reactions": 6, "comments": 11 }, "labels": [ "bug", "context", "app" ], "author": "snrui", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/33493", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-9dea73c2ff6c" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:37425", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Regression in v0.147.0 with LiteLLM provider — streaming requests consistently fail", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? v0.147.0 ### What subscription do you have? Custom litellm provider ### What platform is your computer? AlmaLinux 10.2 (Lavender Lion) ### What issue are you seeing? After upgrading Codex from `v0.146.0` to `v0.147.0`, all requests made through our LiteLLM-backed custom provider fail with the error: **\"We're currently experiencing high demand, which may cause temporary errors.\"** The internal logs repeatedly show `stream disconnected - retrying sampling request` in `codex_core::responses_retry` until the maximum number of retries is reached. Downgrading to `v0.146.0` immediately resolves the issue with no configuration changes. The same LiteLLM endpoint, credentials, models, and configuration work correctly on `v0.146.0`, which suggests a regression in `v0.147.0`, potentially related to streaming or Responses API handling with LiteLLM-compatible providers. ### What steps can reproduce the bug? 1. Configure Codex to use a LiteLLM-backed custom provider. 2. Run Codex with `v0.147.0`. 3. Submit any prompt. 4. The request fails after several retries with the `\"high demand\"` error. 5. Downgrade Codex to `v0.146.0` without changing the configuration. 6. Submit the same prompt again. 7. The request succeeds normally. ### What is the expected behavior? Requests should complete successfully with `v0.147.0`, using the same LiteLLM endpoint and configuration that work correctly with `v0.146.0`. ### Additional information I don't have access to the LiteLLM configuration, as it is managed through our corporate gateway. However, I can confirm that both `gpt-5.6-luna` and `gpt-5.6-terra` work correctly with other coding assistants using the same infrastructure, and they also work correctly with Codex `v0.146.0`. The issue only appears after upgrading to Codex `v0.147.0`. Downgrading back to `v0.146.0` immediately resolves it, which strongly indicates that the regression was introduced in `v0.147.0`. **Regression:** `v0.146.0` ✅ / `v0.147.0` ❌", "url": "https://github.com/openai/codex/issues/37425", "createdAt": "2026-08-07T09:52:31Z", "updatedAt": "2026-08-12T14:48:08Z", "timestamp": "2026-08-12T14:48:08Z", "metrics": { "reactions": 7, "comments": 5 }, "labels": [ "bug", "CLI", "custom-model", "app", "connectivity" ], "author": "CallisteH", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/openai/codex/issues/37425", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-8ac7c880db40" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:37974", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI: queued follow-up inputs are permanently stranded after a failed prompt-edit branch", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What platform is your computer? Linux 5.15.120 x86_64 (also reproducible on other platforms — the bug is in the TUI prompt-edit/backtrack logic, not platform-specific) ### What issue are you seeing? When editing an earlier prompt (Esc-Esc backtrack → select a prompt → Enter), the TUI forks the thread *before* the selected turn. If that fork fails — e.g. the composer shows: ``` ■ Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread ``` — then **any user inputs that were queued while the fork was in flight get permanently stranded**. They stay in \"Queued follow-up inputs\" forever and are never submitted, even after the composer returns to the `Ready` state. The queue just keeps growing with every new message and nothing is ever sent to the model. Note: the \"not found in the persisted thread\" guard itself is legitimate defensive behavior (the visible transcript projection can't always be matched back to a persisted turn — e.g. after history pagination, or when large context blocks are injected as user messages by a wrapper). The bug is purely in the **failure-handling path**, which forgets to re-drive the input queue. ### Root cause Every *successful* fork path re-drives the follow-up input queue via `maybe_send_next_queued_input()`: - the sibling `AppEvent::ForkSession` handler (`codex-rs/tui/src/app/event_dispatch.rs`), - the startup path (`handle_startup_thread_started`), - the thread-start path. But the branch-**failure** path does not. In `codex-rs/tui/src/app_backtrack.rs`: ```rust pub(crate) fn restore_backtrack_prompt_after_branch_error( &mut self, prompt: UserMessage, err: impl std::fmt::Display, ) { self.chat_widget.restore_user_message_to_composer(prompt); self.chat_widget.add_error_message(format!( \"Failed to branch before the selected prompt: {err}\" )); // <-- missing: maybe_send_next_queued_input(); the current thread is still live, // but queued follow-ups are never re-driven, so they stay stuck forever. } ``` Since the fork failed, the original thread stays live, but the queue is never flushed, so queued inputs are stranded. ### What steps can reproduce the bug? 1. In a live thread, enqueue one or more follow-up inputs (e.g. queue messages while a turn is running, or via a wrapper that injects inputs). 2. Trigger prompt editing (Esc-Esc backtrack) and select a prompt whose fork will fail — the reliable way to force the failure is any state where the selected transcript prompt can't be resolved back to a persisted turn (`the selected prompt was not found in the persisted thread`). 3. Observe that after the error, the composer returns to `Ready`, but the queued follow-up inputs remain in \"Queued follow-up inputs\" and are never submitted. ### What is the expected behavior? After a failed prompt-edit branch, since the current thread is still live, queued follow-up inputs should be submitted once the composer is idle — exactly like every successful fork path already does. ### Additional information I have a minimal fix and regression test ready (one-line fix + a test asserting the queued input is submitted after a failed prompt-edit branch, verified to fail without the fix and pass with it). openai/codex does not appear to accept PRs from external forks, so I'm filing this issue instead. Happy to share the patch/branch if useful: ```rust pub(crate) fn restore_backtrack_prompt_after_branch_error( &mut self, prompt: UserMessage, err: impl std::fmt::Display, ) { self.chat_widget.restore_user_message_to_composer(prompt); self.chat_widget.add_error_message(format!( \"Failed to branch before the selected prompt: {err}\" )); // The prompt edit never took effect, so the current thread stays live. Follow-up inputs // queued while the fork was in flight would otherwise remain stuck, because unlike the // successful fork paths this branch never re-drives the queue. Flush it here so queued // messages are submitted once the composer is idle again. self.chat_widget.maybe_send_next_queued_input(); } ```", "url": "https://github.com/openai/codex/issues/37974", "createdAt": "2026-08-11T09:42:39Z", "updatedAt": "2026-08-13T17:59:47Z", "timestamp": "2026-08-13T17:59:47Z", "metrics": { "reactions": 8, "comments": 1 }, "labels": [ "bug", "TUI", "CLI", "session" ], "author": "nil-err", "state": "open", "assignees": [], "change": "new" }, "evidenceUrl": "https://github.com/openai/codex/issues/37974", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-80b1c14dce3d" }, { "tier": "triage-lead", "rankScore": 26, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:vllm-project/vllm:issue:51744", "source": "github", "group": "ai-infrastructure", "project": "vllm-project/vllm", "kind": "issue", "title": "[Bug]: vllm/vllm-openai:latest fails to start Gemma4 with Transformers 5.15.0", "text": "### Your current environment ```text Docker image: vllm/vllm-openai:latest vLLM: 0.27.0 Transformers: 5.15.0 Model: yasu-oh/gemma-4-31B-it-qat-NVFP4 Tensor parallel size: 2 KV cache dtype: fp8 ``` The Transformers version in the image can be confirmed with: ```bash docker run --rm \\ --entrypoint python3 \\ vllm/vllm-openai:latest \\ -c 'import vllm, transformers; print(\"vLLM:\", vllm.__version__); print(\"Transformers:\", transformers.__version__)' ``` Output: ```text vLLM: 0.27.0 Transformers: 5.15.0 ``` ### 🐛 Describe the bug The current official release image `vllm/vllm-openai:latest` contains: ```text vLLM: 0.27.0 Transformers: 5.15.0 ``` When serving: ```text yasu-oh/gemma-4-31B-it-qat-NVFP4 ``` vLLM fails during startup with: ```text transformers.integrations.heterogeneity.configuration_utils.AmbiguousGlobalPerLayerAttributeError: 'head_dim' is a per-layer attribute and may vary across layers. Access it via config.per_layer_config[i].head_dim. ``` The exception occurs in: ```text vllm/transformers_utils/model_arch_config_convertor.py ``` while accessing the Gemma4 `head_dim`. ### Workaround Downgrading only Transformers to 5.14.1 while keeping the same `vllm/vllm-openai:latest` base image and serving configuration resolves the issue. ```dockerfile FROM vllm/vllm-openai:latest RUN /usr/bin/python3 -m pip install --no-cache-dir 'transformers==5.14.1' ``` With Transformers 5.14.1: * the same model loads successfully, * the vLLM engine initializes successfully, * the API server starts successfully, * `/v1/chat/completions` returns HTTP 200, * 32 concurrent requests run successfully. ## Related PRs * #49797 ? Fix Gemma 4 for upcoming Transformers version * #49959 ? Handle Transformers 5.15 Gemma4 schema ### Before submitting a new issue... - [x] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the [documentation page](https://docs.vllm.ai/en/latest/), which can answer lots of frequently asked questions.", "url": "https://github.com/vllm-project/vllm/issues/51744", "createdAt": "2026-08-11T00:42:58Z", "updatedAt": "2026-08-13T14:26:47Z", "timestamp": "2026-08-13T14:26:47Z", "metrics": { "reactions": 5, "comments": 14 }, "labels": [ "bug" ], "author": "yasu-oh", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/vllm-project/vllm/issues/51744", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm.html#signal-bb8d76fa55e5" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:67021", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Bundled ugrep OOMs the host: -E with two bounded {0,N} intervals explodes DFA construction to multiple GB", "text": "### What happened Claude Code's bundled `ugrep` (the CLI re-execs its own binary as `ugrep`, argv0=`ugrep`) allocates unbounded memory during **regex compilation** when run with `-E` (POSIX extended regex) on a pattern containing **two bounded `.{0,N}` intervals**. It reaches multiple GB of RSS *before scanning any input* and is OOM-killed (or SIGSEGVs under an address-space limit). On a 12 GB Linux host this repeatedly killed whole Claude Code sessions. Captured processes reached **4.3 GB** and **8.0 GB** RSS; the kernel OOM-killer took down the session each time. The triggering process was a real Grep/search invocation of the form: ``` ugrep -E -o '.{0,40}(session-corpus|short-term-recall|...).{0,30}' ``` The 74 KB file is irrelevant — the process dies in DFA construction, before reading data. ### Minimal reproduction (verified) ```bash # point a name \"ugrep\" at the bundled binary (adjust the version string) ln -sf ~/.local/share/claude/versions/2.1.170 /tmp/ugrep printf 'x\\n' > /tmp/f # BAD: RSS climbs to the 2.5 GB cap, then SIGSEGV (exit 139), zero output ( ulimit -v 2500000; /tmp/ugrep -E -o '.{0,40}abc.{0,30}' /tmp/f ) # GOOD: identical pattern under PCRE2 -> ~8 MB, instant, exits cleanly ( ulimit -v 2500000; /tmp/ugrep -P -o '.{0,40}abc.{0,30}' /tmp/f ) ``` Narrowing: - **Two** bounded intervals are required: `.{0,40}abc.{0,30}` explodes; a single `.{0,80}abc` is fine. - `-o` and alternation are **not** required. - Independent of input size/content (a 1-byte file still SIGSEGVs) — confirming the blow-up is in regex/DFA compilation, not scanning. - Measured: `-E` peaks at the imposed cap (~2.37 GB) and SIGSEGVs after ~15–27 s of CPU; `-P`, `-G`, and `-F` all finish instantly at ~8 MB. ### Expected Bounded memory: compile the ERE efficiently, or cap memory and exit with an error. ### Actual Multi-GB allocation during regex compilation → OOM-kill / SIGSEGV. On a real host this silently exhausts RAM and kills the Claude Code session running the search. ### Environment - Claude Code **2.1.170** (native install), bundled `ugrep`, Node v24 SEA - Linux (Fedora 44, x86-64), 12 GB RAM ### Suggested fix Use `-P` (PCRE2) for Grep patterns containing `.{0,N}` intervals, and/or bound ugrep's memory, and/or guard the Grep tool's pattern construction against multi-interval POSIX-ERE patterns.", "url": "https://github.com/anthropics/claude-code/issues/67021", "createdAt": "2026-06-10T13:51:36Z", "updatedAt": "2026-08-13T09:07:32Z", "timestamp": "2026-08-13T09:07:32Z", "metrics": { "reactions": 3, "comments": 18 }, "labels": [ "bug", "has repro", "platform:linux", "area:tools", "perf:memory" ], "author": "interkelstar", "state": "open", "assignees": [], "change": "updated" }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/67021", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-ea6bb6ff3154" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:70062", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] 'claude-api' is consuming entire context", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When attempting to ask a question in non-interactive mode (prompt was \"Have the changes for 'non-interactive' usage rates gone into effect?\"), the 'claude-api' skill is being loaded and consuming the entire context, resulting in the 'Prompt is too long' error. Claude's summary of the issue: **Session metadata** (anonymized): ``` sessionId: [REDACTED] cwd: /home/[USER]/delete/tmp version: 2.1.176 ``` **1. User prompt sent:** ```json {\"type\":\"user\",\"message\":{\"role\":\"user\",\"content\":\"Have the changes for 'non-interactive' usage rates gone into effect?\"},\"entrypoint\":\"sdk-cli\"} ``` **2. Skill listing loaded at session start** (showing `claude-api` among active skills): ```json {\"attachment\":{\"type\":\"skill_listing\",\"names\":[\"grill-me\",\"lazydm-session\",\"deep-research\",\"skill-creator:skill-creator\",\"update-config\",\"keybindings-help\",\"verify\",\"code-review\",\"simplify\",\"fewer-permission-prompts\",\"loop\",\"schedule\",\"claude-api\",\"run\",\"init\",\"review\",\"security-review\"],\"isInitial\":true}} ``` **3. Claude decides to invoke the `claude-api` skill:** ```json {\"message\":{\"content\":[{\"type\":\"tool_use\",\"name\":\"Skill\",\"input\":{\"skill\":\"claude-api\"}}],\"stop_reason\":\"tool_use\"}} ``` **4. Skill content loaded** — the full contents of the bundled `claude-api` SKILL.md are injected as a tool result. The content includes complete API reference documentation for C#, Go, Java, PHP, Python, TypeScript, cURL, managed agents, model migration guides, and more. Total size is several hundred KB. **5. Immediate error:** ```json {\"message\":{\"content\":[{\"type\":\"text\",\"text\":\"Prompt is too long\"}],\"error\":\"invalid_request\",\"isApiErrorMessage\":true}} ``` --- **Summary for bug report:** In `-p` (non-interactive) mode, a 10-word conversational prompt triggered the bundled `claude-api` skill, which loaded its entire documentation contents into the context. The resulting prompt exceeded the model's context limit, producing a \"Prompt is too long\" error on a fresh session. Running with `--safe-mode` (which disables skills) resolves the issue. ### What Should Happen? The skill shouldn't consume the entire context, blocking usage. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce While on Claude Code version 2.1.176: `claude -p \"Have the changes for 'non-interactive' usage rates gone into effect? \"` ### Claude Model Sonnet (default) ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.176 ### Platform Anthropic API ### Operating System Other Linux ### Terminal/Shell Other ### Additional Information I am using the Alacritty terminal on Manjaro Linux", "url": "https://github.com/anthropics/claude-code/issues/70062", "createdAt": "2026-06-22T14:48:47Z", "updatedAt": "2026-08-13T13:52:41Z", "timestamp": "2026-08-13T13:52:41Z", "metrics": { "reactions": 5, "comments": 10 }, "labels": [ "bug", "has repro", "platform:linux", "area:skills" ], "author": "SenojLuap", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/70062", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-76632dbb9682" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:76694", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Cowork: new projects lost \"Choose a folder\" — Context menu replaced with Chat-style upload-only knowledge menu after Chat/Cowork merge", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Summary Since the Chat/Cowork merge rollout (~July 8–9, 2026), **newly created projects no longer offer the \"Choose a folder\" option** in the Context panel. The Cowork-native context menu has been replaced wholesale with the Chat-style project knowledge menu, which only supports static context (file uploads, pasted text, GitHub/Drive/Notion imports). There is no way to link a local folder to a new project for dynamic, living-file context. Projects created **before** the merge retain the old menu and their linked folders (grandfathered). ## Steps to Reproduce 1. Claude Desktop on macOS, post-merge build (merge rolled out ~July 8–9, 2026) 2. Create a **new** project 3. In the project view, click the **+** next to **Context** 4. Observe the menu options ## Actual Behavior Context \"+\" menu on new projects shows only: - Upload from device - Add text content - GitHub - Drive - Notion This is the Chat project \"knowledge\" menu (static snapshot context). \"Choose a folder\" is absent entirely — this is not a folder-picker validation failure; the menu itself is different. Even the Context empty-state copy is Chat's (\"Add PDFs, docs…\"). ## Comparison (screenshots attached) - **Screenshot 1 — pre-merge project:** Context \"+\" → Choose a folder / Drive / Add a link. Multiple locally linked folders visible and working in the Context list. - **Screenshot 2 — project created post-merge:** Context \"+\" → Upload from device / Add text content / GitHub / Drive / Notion. No folder option. ## Why This Matters Linking a folder (dynamic context tied to living files, e.g. Obsidian vaults that sessions read and write) is categorically different from uploading files (static snapshot). Folder-linked projects are the core Cowork workflow; new projects currently cannot use it at all. ## Environment - **OS:** macOS (Apple Silicon MacBook Pro) - **App:** Claude Desktop, post-merge build (auto-updated ~July 9, 2026) - **Regression:** Yes — worked until the Chat/Cowork merge rollout; discovered July 10, 2026 ## Related Issues (same rollout window) - #76604 — Cowork broken since Chat/Cowork merge: projects disappear within 24h - #76254 — trusted-folder validation rejects previously-accepted folders since ~July 9 update; existing grants grandfathered - #76344 — connected folders no longer writable-mounted since mandatory write-consent change (~July 8) - #76573 — cannot remove a project's original folder from context ## Notes - Pre-merge projects keep the old Context menu and their folder links — consistent with grandfathered grants noted in #76254. (Users should be warned not to unlink folders from old projects, since re-adding appears impossible in new-style projects.) - In-session \"Add folder\" (session-level device bridge) still functions, but is per-session and not persisted as project context — a partial workaround, not a substitute. \"Image\" \"Image\" ### What Should Happen? The Context \"+\" menu on a newly created project should offer **Choose a folder** (link a local folder on this computer as live, dynamic project context), plus Drive and Add a link — exactly as pre-merge projects still show, and as documented in the support article \"Organize your tasks with projects in Claude Cowork\" (\"Use an existing folder on your computer\"). ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Use Claude Desktop on macOS with a post-merge build (auto-updated during the Chat/Cowork merge rollout, ~July 8–9, 2026) 2. Create a **new** project 3. In the project view, click the **+** button next to **Context** 4. Observe the menu: **Upload from device / Add text content / GitHub / Drive / Notion** — \"Choose a folder\" is absent 5. For comparison, open any project created **before** the merge and click the same **+** next to Context: the menu shows **Choose a folder / Drive / Add a link**, and previously linked local folders are still listed and working Result: there is no way to link a local folder (dynamic, living-file context) to any newly created project — only static uploads/imports. ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version Pre-merge Claude Desktop build (working as of July 7, 2026) ### Claude Code Version 1.20186.1 (df1d8a) ### Platform Other ### Operating System macOS ### Terminal/Shell Other ### Additional Information **Note on scope:** This is a Claude Desktop (Cowork) issue, not the Claude Code CLI — filed here because Cowork/desktop regressions from the same rollout are tracked in this repo with the `area:cowork` / `area:desktop` labels (e.g. #76604, #76254, #76344, #76573). The \"Claude Code Version\" field below therefore contains the Claude Desktop app version. **Screenshots:** two attached above in \"What's Wrong?\" — (1) a pre-merge project's Context \"+\" menu showing \"Choose a folder\", (2) a post-merge new project's Context \"+\" menu showing the upload-only Chat-style options. **Documentation reference:** the Claude Help Center article \"Organize your tasks with projects in Claude Cowork\" still documents \"Use an existing folder on your computer\" as a context option for projects.", "url": "https://github.com/anthropics/claude-code/issues/76694", "createdAt": "2026-07-11T15:17:36Z", "updatedAt": "2026-08-13T11:59:52Z", "timestamp": "2026-08-13T11:59:52Z", "metrics": { "reactions": 5, "comments": 10 }, "labels": [ "bug", "platform:macos", "area:cowork", "area:desktop" ], "author": "rexilx", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/76694", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-d5fbdae59743" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:81341", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Desktop MSIX: CIG (MicrosoftSignedOnly) + vendor-signed vk_swiftshader.dll kills GPU process on every browser preview (0x060C201E)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? On Windows 11 (build 26200), Claude Desktop 1.24012.9.0 (MSIX) crashes deterministically seconds after an agent opens a **browser preview** in the Code tab. The GPU child process dies with unhandled exception 0x060C201E, five relaunches fail (error_code=18), and the app self-terminates: `FATAL: GPU process isn't usable. Goodbye.` Windows then flags the package `Modified, NeedsRemediation`, so every crash also requires full Remove-AppxPackage + reinstall. 15 crashes captured, all second-exact correlated with CodeIntegrity events. **Root cause (verified):** The GPU child runs with **MicrosoftSignedOnly (CIG): ON** (verified via Get-ProcessMitigation on the live process), but the package ships `app\\vk_swiftshader.dll` signed by \"Anthropic, PBC\" (DigiCert) - valid Authenticode, but not Microsoft signing level - and no `AppxMetadata\\CodeIntegrity.cat` (verified missing on disk AND inside the downloaded MSIX). When browser-preview's WebRTC path probes Vulkan, the GPU process loads vk_swiftshader.dll, CIG rejects it, and because the app is MSIX-packaged the loader escalates to `ntdll!LdrAppxHandleIntegrityFailure` and kills the process. Full ProcDump dump of the GPU child captured at the exact moment (WinDbg FAILURE_BUCKET: APPLICATION_FAULT_60c201e_ntdll.dll!LdrAppxHandleIntegrityFailure). **Control group:** Chrome on the same machine has the identical MicrosoftSignedOnly:ON on its GPU process, logs the identical CodeIntegrity 3033 event for its own vk_swiftshader.dll - and survives, because it is not MSIX-packaged. Packaging is the only difference. **Exonerated by 30+ hours of isolation:** Intel drivers 32.0.101.8331 AND 32.0.101.8860 WHQL clean install (identical crash on both); hardware (0 TDR / 0 WHEA in 30 days, disk healthy); fresh GPU caches; fresh package (Status=Ok); --no-sandbox / --disable-gpu-sandbox; clean zombie-SID scan; canonical WindowsApps ACLs; zero third-party DLLs (Defender only). **Workaround (confirmed):** installing the non-MSIX build (`Claude Setup.exe --exe`) fully resolves it - same version, same CIG policy, same 3033 event, but the load failure is non-fatal outside MSIX. Browser previews work. **Suggested fix:** drop MicrosoftSignedOnly on the GPU process in the MSIX build, or gate the Vulkan/swiftshader probe, or ship the DLL at the required signing level / with a CI catalog. Related: #61372, #49676, #56679, #36157, electron/electron#51761 ### What Should Happen? Opening a browser preview should not crash the app. The GPU process should either load vk_swiftshader.dll successfully or fail the Vulkan probe gracefully (as Chrome does with the identical file and identical CIG policy) and fall back without terminating. The package should never flip to NeedsRemediation. ### Error Messages/Logs ```shell [net] Failed to resolve address for stun.cloudflare.com / stun.l.google.com (WebRTC session setup) <1 second later: ERROR:gpu_process_host.cc(998) GPU process exited unexpectedly: exit_code=101457950 ERROR:gpu_process_host.cc(992) GPU process launch failed: error_code=18 (x5) FATAL:gpu_data_manager_impl_private.cc(418) GPU process isn't usable. Goodbye. CodeIntegrity/Operational log, second-exact with every crash (15/15): Event 3010 x3: Code Integrity was unable to load the ...\\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\\AppxMetadata\\CodeIntegrity.cat catalog. Status 0xC000003A. Event 3033: claude.exe attempted to load ...\\app\\vk_swiftshader.dll that did not meet the Microsoft signing level requirements. WinDbg on the ProcDump dump of the GPU child: EXCEPTION_CODE: 60c201e (unhandled) SYMBOL_NAME: ntdll!LdrAppxHandleIntegrityFailure FAILURE_BUCKET_ID: APPLICATION_FAULT_60c201e_ntdll.dll!LdrAppxHandleIntegrityFailure Live GPU child mitigation (Get-ProcessMitigation -Id ): MicrosoftSignedOnly: ON vk_swiftshader.dll signature: Valid, Signer CN=\"Anthropic, PBC\" (DigiCert) - not Microsoft level ``` ### Steps to Reproduce 1. Windows 11 25H2 build 26200, Intel Arc iGPU (Core Ultra), VBS/HVCI on, Defender only 2. Install Claude Desktop 1.24012.9.0 via the standard MSIX installer 3. Open the Code tab, start an agent session 4. Have the agent open a **browser preview** 5. Within 7-11 seconds: WebRTC STUN lookups appear in the log, the GPU child dies (0x060C201E), the whole app terminates 6. Windows Settings now shows the app needs Repair; package Status = Modified, NeedsRemediation; Repair fails; only full reinstall recovers - until the next preview Deterministic: 15/15 previews with the MSIX build crashed. 0 crashes with the non-MSIX build (--exe) on the same machine. ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 1.22209.3 ### Claude Code Version 1.24012.9.0 (Claude Desktop MSIX); non-MSIX build 1.24012.9 unaffected ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information Available on request (privately - dumps contain environment data): ProcDump full dump of the GPU child, CodeIntegrity event log export, main.log, two Electron stderr captures showing the STUN-to-death fingerprint, driver A/B results, full diagnostic matrix report.", "url": "https://github.com/anthropics/claude-code/issues/81341", "createdAt": "2026-07-26T10:47:29Z", "updatedAt": "2026-08-13T12:42:15Z", "timestamp": "2026-08-13T12:42:15Z", "metrics": { "reactions": 3, "comments": 16 }, "labels": [ "bug" ], "author": "allarounderservices", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/81341", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-57cbb1442970" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:anthropics/claude-code:issue:82092", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Apps gateway serves Claude Desktop an `otlpEndpoint` pointing at its own bearer-gated OTLP ingest but no `otlpHeaders`, so every Desktop telemetry flush is rejected with `missing_token`", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Summary A Claude apps gateway with `telemetry.forward_to` configured and a `desktop` block in a managed policy serves Claude Desktop a `GET /user/bootstrap` response containing `otlpEndpoint` set to `listen.public_url` — the gateway's own origin — and **no `otlpHeaders`**. The gateway's OTLP ingest endpoints require a bearer token (`POST /v1/metrics`, `/v1/logs`, `/v1/traces`, per the gateway protocol reference). `otlpHeaders` is the only mechanism Claude Desktop has for attaching credentials to its OTLP exports. Because bootstrap populates the endpoint but not the headers, Desktop posts unauthenticated to an endpoint that mandates authentication, and 100% of Desktop telemetry is dropped at the door. No client-side or MDM setting can fix this: the credential the endpoint wants is a per-user device-flow token with (in our case) a 1-hour TTL, and MDM `otlpHeaders` values are necessarily static. Claude Code CLI telemetry through the same gateway works correctly — it authenticates with its session bearer and the gateway relays to `forward_to`. Desktop is the only affected client. ## Environment - Gateway server: `claude` 2.1.220, self-hosted (ECS Fargate behind an ALB) - Claude Desktop on Windows 11, managed via `HKLM\\SOFTWARE\\Policies\\Claude` - Auth: OIDC, `session.ttl_hours: 1` - Upstream: Amazon Bedrock - Telemetry destination: OTLP/HTTP collector reached via `telemetry.forward_to` ## Notes / supporting detail - The gateway protocol reference documents the telemetry endpoints as `POST /v1/metrics`, `/v1/logs`, `/v1/traces` **(bearer)**, and states that when connected to a gateway the client sends telemetry there and ignores `OTEL_EXPORTER_OTLP_*` env vars — so the env-var path documented for CLI clients isn't available as a workaround either. - The gateway config reference notes that `telemetry.forward_to` + `listen.public_url` enables telemetry and that the CLI stamps `user.id`/`user.email`/`user.groups` from the JWT. Desktop instead receives `enduser.id` as a resource attribute, so even once ingest is unblocked, Desktop and CLI telemetry arrive under different attribute names and don't aggregate on the same dashboards without a collector-side rename. - For contrast, AWS's reference implementation of a third-party bootstrap server (`aws-solutions-library-samples/guidance-for-claude-code-with-amazon-bedrock`, PRs #669/#670) returns `otlpEndpoint` together with `otlpHeaders` carrying per-user identity, and points the endpoint at a collector rather than at the bootstrap server itself. That appears to be the intended shape of a bootstrap response; the first-party gateway does neither. ## Why there is no client-side workaround An MDM `otlpHeaders` value cannot substitute for the missing one. Per the [bootstrap server docs](https://claude.com/docs/third-party/claude-desktop/bootstrap): > When a bootstrap response is available, it **is** the effective configuration. The MDM profile supplies the trust anchor (`bootstrapUrl`, optional `bootstrapOidc`, and the `bootstrapEnabled` opt-out), and Claude Desktop does not consult MDM for any key the bootstrap server is permitted to set. A bootstrap-settable key that your response **omits** is treated as unset, not inherited from MDM, so return every key you want applied. `otlpHeaders` is marked `MDM + Bootstrap` in the configuration reference, so it is bootstrap-settable and an MDM value for it is ignored while `bootstrapUrl` is configured. Combined with the gateway not emitting the key, there is no path by which Desktop can obtain an OTLP credential. The only ways out are both unattractive: 1. Terminate the OTLP paths at the load balancer ahead of the gateway and accept them **unauthenticated**, since no credential can be delivered to distinguish legitimate clients. 2. Abandon bootstrap for Desktop (`bootstrapEnabled: false`) and configure the whole client through MDM, which restores `otlpHeaders` but gives up per-group policy, the gateway-derived model list, and per-user config delivery — the reasons to run a bootstrap server at all. Neither preserves both authenticated telemetry ingest and gateway-delivered policy, which is why this reads as a gap rather than a configuration mistake. ### What Should Happen? One of: 1. **Bootstrap includes a usable credential** — e.g. `otlpHeaders: {\"Authorization\": \"Bearer \"}`. This looks like the natural fix: the response already carries `expiresAt` and Desktop refetches bootstrap periodically (~30 min in our observation), comfortably inside a 1-hour `session.ttl_hours`, so the token would rotate on the existing refresh cycle. 2. **The gateway accepts Desktop's exports without a bearer** on a distinguishable basis, or supports a second inbound auth mode for the OTLP paths (a static ingest token configurable in `gateway.yaml`). There is currently no such key — `telemetry.forward_to[].headers` is outbound-only and `access_control` is CIDR-based. 3. **Bootstrap omits `otlpEndpoint`** when it can't supply a credential, so Desktop falls back to the MDM-configured endpoint instead of silently failing against the gateway. At minimum, the gateway should not advertise an endpoint it will then reject, and the mismatch should be visible: today it is silent from the operator's perspective unless someone reads the ingest logs, and silent from the user's perspective entirely. ### Error Messages/Logs ```shell The bootstrap response: { \"inferenceProvider\": \"gateway\", \"inferenceGatewayBaseUrl\": \"https://claude-gateway.example.internal\", \"inferenceGatewayAuthScheme\": \"sso\", \"otlpEndpoint\": \"https://claude-gateway.example.internal\", \"otlpProtocol\": \"http/json\", \"otlpResourceAttributes\": { \"enduser.id\": \"user@example.com\" }, \"inferenceModels\": [ \"...5 models...\" ], \"expiresAt\": 1785254860 } Note `otlpEndpoint` is present and `otlpHeaders` is absent. Every subsequent Desktop flush is refused: {\"ts\":\"2026-07-28T14:13:09.918Z\",\"evt\":\"auth.denied\",\"request_id\":\"...\",\"reason\":\"missing_token\",\"path\":\"/v1/logs\",\"client_ip\":\"...\"} {\"ts\":\"2026-07-28T14:35:22.104Z\",\"evt\":\"auth.denied\",\"request_id\":\"...\",\"reason\":\"missing_token\",\"path\":\"/v1/metrics\",\"client_ip\":\"...\"} Meanwhile `desktop_bootstrap.serve` events for the same user return 200 throughout, so this isn't a policy-matching or opt-in problem — bootstrap is working, it just hands over an unusable telemetry configuration. ``` ### Steps to Reproduce 1. Configure a gateway with both `listen.public_url` and `telemetry.forward_to` (this is the documented pair that enables telemetry), plus a managed policy carrying a `desktop` block so `GET /user/bootstrap` serves instead of 404ing: ```yaml listen: public_url: https://claude-gateway.example.internal telemetry: forward_to: - url: http://localhost:4318 metrics: true logs: true managed: policies: - match: {} desktop: {} ``` 2. Point Claude Desktop at it with `bootstrapUrl` + `bootstrapEnabled` via managed configuration and sign in. Bootstrap succeeds — the user gets the model list and gateway inference works. 3. Watch the gateway logs as Desktop flushes telemetry. ### Claude Model Not sure / Multiple models ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.220 ### Platform AWS Bedrock ### Operating System Windows ### Terminal/Shell Other ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/82092", "createdAt": "2026-07-28T20:23:33Z", "updatedAt": "2026-08-13T16:32:19Z", "timestamp": "2026-08-13T16:32:19Z", "metrics": { "reactions": 5, "comments": 9 }, "labels": [ "bug" ], "author": "k-brooks", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/anthropics/claude-code/issues/82092", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/2/#signal-f8a9c84a2f09" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:containerd/containerd:issue:12738", "source": "github", "group": "platform-infrastructure", "project": "containerd/containerd", "kind": "issue", "title": "Continuous memory growth in containerd v2.1.4", "text": "### Description We are seeing continuous memory growth on `containerd` version `github.com/containerd/containerd/v2 2.1.4` in our AWS EKS v1.32 cluster. The containerd process memory grows constantly and reaches maximum capacity and causes the node to become non-responsive and also causes OS to kill other things abruptly due to memory pressure causing node to go into `NotReady` status. ### Steps to reproduce the issue We simply keep it running for a few days and memory grows. (Note: We have duplicate metrics. So two same value lines are shown. Ignore one) \"Image\" ### Describe the results you received and expected Memory should not grow unbounded like this. ### What version of containerd are you using? containerd github.com/containerd/containerd/v2 2.1.4 75cb2b7193e4e490e9fbdc236c0e811ccaba3376 ### Any other relevant information We also use these nodes for running periodic Argo jobs (short-lived jobs run periodically every 2mins, etc.). I am not sure if this has any relation. ### Show configuration if it is related to CRI plugin. _No response_", "url": "https://github.com/containerd/containerd/issues/12738", "createdAt": "2026-01-01T08:39:25Z", "updatedAt": "2026-08-13T00:19:44Z", "timestamp": "2026-08-13T00:19:44Z", "metrics": { "reactions": 2, "comments": 20 }, "labels": [ "kind/bug", "area/runtime" ], "author": "spy16x", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/containerd/containerd/issues/12738", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/containerd.html#signal-e5c1c8c0d735" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:17316", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Switching global provider hides previous sessions from the sidebar", "text": "### What feature would you like to see? Switching the global provider should not make previous chat sessions disappear from the Codex app sidebar. ### Current behavior - I create sessions with one provider. - I switch the global provider. - Older sessions no longer appear in the sidebar. ### Expected behavior Previous sessions should remain visible and accessible even after changing provider. If sessions are being filtered by provider, the UI should make that explicit and let me view sessions from other providers. ### Why this matters Changing provider is a normal workflow when testing OpenAI, Azure, or local models. It should not hide session history.", "url": "https://github.com/openai/codex/issues/17316", "createdAt": "2026-04-10T08:28:03Z", "updatedAt": "2026-08-13T04:15:39Z", "timestamp": "2026-08-13T04:15:39Z", "metrics": { "reactions": 8, "comments": 12 }, "labels": [ "enhancement", "custom-model", "app" ], "author": "bakaburg1", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/17316", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-072408eec778" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned enhancement with community reactions" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:23517", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "request setting to disable autoscroll", "text": "### What variant of Codex are you using? App ### What feature would you like to see? I find the autoscroll during the Codex response to be visually uncomfortable - especially for longer messages. This is, I think, my preferred behavior: - a space is afforded for a short response that requires no scrolling (~10 lines) - if the output goes beyond that space, there is a small visual cue (arrow) but no autoscroll - user can scroll to see the rest of the message Please make this a setting - or even the default Stretch: - afforded space is also controllable (10 lines? 20 lines?) - afforded space (controlled by user) is interpreted by Codex as the desired length for \"typical conversational exchange\" -- longer responses are tied to specific requests by the user or are determined through context ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/23517", "createdAt": "2026-05-19T18:11:43Z", "updatedAt": "2026-08-12T21:53:43Z", "timestamp": "2026-08-12T21:53:43Z", "metrics": { "reactions": 10, "comments": 5 }, "labels": [ "enhancement", "app" ], "author": "mohnjahoney", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/23517", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-1fccbeadb596" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:32492", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows app stuck on \"Finish Windows setup\" — sandbox setup never triggers a real UAC prompt, \"Retry\" fails instantly", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Unknown — the app is blocked on the \"Finish Windows setup\" screen and I cannot reach the About dialog. ### What subscription do you have? Plus ### What platform is your computer? \"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { \"x64\" } else { \"x86\" })\" ### What issue are you seeing? On first launch the Windows app is stuck on the \"Finish Windows setup\" screen (\"ChatGPT necesita un permiso por única vez para funcionar en tu computadora\"). It always shows \"La instalación de Windows no se completó\", and clicking \"Reintentar la configuración de Windows\" fails instantly. No real Windows UAC prompt ever appears when clicking Retry — the UAC dialog shown on that screen is only an illustration, and no actual elevation request is triggered. The setup gate blocks before the app is usable at all. ### What steps can reproduce the bug? 1. Install the ChatGPT/Codex desktop app from the Microsoft Store on Windows 11 Pro. 2. Launch the app. 3. It shows \"Finish Windows setup\" requesting a one-time permission. 4. Click \"Reintentar la configuración de Windows\" — it fails immediately with \"La instalación de Windows no se completó\". No real UAC prompt appears. Already verified/attempted, none resolves it: - CPU virtualization: enabled (confirmed in Task Manager) - VirtualMachinePlatform and Containers-DisposableClientVM features: both enabled, rebooted - Local Administrator account; \"Run as administrator\" → same error - UAC at default level; AppInfo service running - Clean reinstall from Microsoft Store → same error - Reset %USERPROFILE%\\.codex → same error - \"Continuar con acceso limitado\" also fails - Added [windows] sandbox = \"wsl\" to config.toml → no effect (setup gate blocks before it's read) Workaround: Codex CLI inside WSL2 works fine, which points to the native Windows sandbox setup step being the broken component. Looks related to issues #26737 and #26883. ### What is the expected behavior? The app should complete the one-time Windows setup and open normally. \"Image\" ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/32492", "createdAt": "2026-07-11T23:23:37Z", "updatedAt": "2026-08-13T04:32:50Z", "timestamp": "2026-08-13T04:32:50Z", "metrics": { "reactions": 5, "comments": 10 }, "labels": [ "bug", "windows-os", "sandbox", "app" ], "author": "joseluisjl4", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/32492", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-778928404f67" }, { "tier": "triage-lead", "rankScore": 25, "reasons": [ "Unassigned bug with visible community engagement" ], "caveat": "No explicit contribution invitation was found; ask maintainers whether a contribution is wanted.", "signal": { "id": "github:openai/codex:issue:34268", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Multi-agent V2 full-history forks duplicate historical compaction snapshots and inline images, causing >100 GiB session storage growth", "text": "### What issue are you seeing? A long-running Codex Desktop conversation using Ultra reasoning and multi-agent V2 produced approximately 110 GiB of local session data under `$CODEX_HOME/sessions`. The growth appears multiplicative rather than being caused by subagents producing unusually large outputs: 1. Context compaction persists `Compacted` rollout records containing a complete `replacement_history`. 2. These replacement histories can contain inline base64-encoded screenshots. 3. Older compaction records remain in the append-only parent rollout. 4. A full-history subagent fork loads the parent’s persisted rollout items. 5. Those inherited items—including all historical compaction snapshots—are serialized into the child rollout. 6. Ultra reasoning proactively creates many subagents, multiplying the retained history across many files. Observed impact from one session tree: | Measurement | Result | |---|---:| | Total rollout files | 300 | | Total reported size | approximately 110.09 GiB | | Subagent rollout files | 294 | | Size attributed to subagent rollouts | approximately 106.56 GiB | | Files sharing the same root session ID | 295 | | Files at least 1 GB | 51 | | Files at least 500 MB | 86 | | Files at least 100 MB | 155 | Of those files, 159 were recorded by `0.145.0-alpha.18` with `multi_agent_version: \"v2\"` and accounted for approximately 88.18 GiB. Many individual subagent rollouts were between 1.3 GB and 1.9 GB. A representative completed child rollout was `1,706,557,797` bytes and contained 23,564 JSONL records. Its composition was: - 141 `compacted` records - Approximately 1.55 GiB in `compacted` records - 97.6% of the entire file attributable to `compacted` records - 125 individual JSONL records larger than 10 MB - Largest JSONL record approximately 12.93 MiB One inspected `replacement_history` contained: - 118 history items - 19 `input_image` entries - 13,316,621 characters of inline `data:image/png;base64,...` data - Approximately 197,716 characters of input text The child files are not small records that merely reference their parent. A representative child begins with its own `session_meta`, followed by a copy of the parent’s original `session_meta` and inherited parent events. Sampled parent payloads were identical, while outer timestamps were rewritten to the child creation time and some response items received new IDs. The files have separate inodes and link counts of `1`, and their allocated sizes are close to their logical sizes. This appears to be independently serialized history rather than sparse files or parent references. This can consume enough storage to exhaust a local disk during a single long-running Ultra session. ### What steps can reproduce the bug? The severity depends on having a sufficiently large parent history, multiple compactions, inline images, and multiple full-history forks. 1. Start a persisted local Codex thread using Codex Desktop or another local surface backed by the shared Codex runtime. 2. Use the same thread for an extended period. 3. Add several screenshots or other image inputs to the conversation. 4. Continue the conversation long enough to trigger multiple context compactions. 5. Select Ultra reasoning with multi-agent V2 enabled. 6. Give Codex work that causes it to proactively spawn multiple subagents. 7. Allow the generated `spawn_agent` calls to omit `fork_turns`. In multi-agent V2, the omitted value defaults to `\"all\"`. 8. Inspect the newly created child rollouts under `$CODEX_HOME/sessions`. 9. Compare their sizes and initial JSONL records with the parent rollout. 10. Repeat with additional subagents and observe that each full-history child can approach the persisted historical size of the parent before doing significant child-specific work. Example read-only inspection commands: du -sh \"$CODEX_HOME/sessions\" find \"$CODEX_HOME/sessions\" -type f -name '*.jsonl' -print0 \\ | xargs -0 stat -f '%z %N' \\ | sort -nr \\ | head -50 For a suspected child file: head -n 1 \"$CHILD_ROLLOUT\" \\ | jq '.payload | { id, session_id, thread_source, forked_from_id, parent_thread_id, multi_agent_version, source }' The child metadata should identify it as a subagent and point to the parent through `parent_thread_id` and/or `forked_from_id`. Inspecting the first several records should show the child’s new `session_meta` followed by inherited parent rollout records. The problem becomes increasingly visible as these factors increase: - Number of retained compaction records - Number and size of inline images - Length of the parent thread - Number of spawned subagents - Use of full-history/default `fork_turns=\"all\"` behavior ### What is the expected behavior? Spawning subagents should not cause local persisted session storage to grow in proportion to the parent’s complete append-only rollout history for every child, particularly when the history contains multiple historical compaction snapshots representing earlier versions of substantially the same model context. A newly spawned child should not routinely approach 1–2 GB before performing meaningful child-specific work. Disk growth should remain bounded enough that proactive multi-agent behavior cannot unexpectedly create more than 100 GiB of local session data from one conversation tree. This expectation applies regardless of whether the triggering surface is Codex Desktop, the CLI, or `codex exec`, since the relevant multi-agent and rollout-persistence behavior appears to be shared. ### Additional information Environment and metadata from the affected session: - Platform: macOS - Surface: Codex Desktop - Reasoning mode: Ultra - Root metadata: - `originator: \"Codex Desktop\"` - `source: \"vscode\"` - `history_mode: \"legacy\"` - Child metadata: - `thread_source: \"subagent\"` - `multi_agent_version: \"v2\"` - Codex versions present: - `0.144.2` - `0.144.5` - `0.145.0-alpha.18` Relevant source locations: - `codex-rs/core/src/session/multi_agents.rs` - `effective_multi_agent_mode` maps Ultra reasoning to proactive multi-agent behavior. - The behavior applies to `SessionSource::Cli`, `SessionSource::VSCode`, `SessionSource::Exec`, and other sources. - `codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs` - `SpawnAgentArgs::fork_mode` defaults omitted or empty `fork_turns` to `\"all\"`. - `\"all\"` becomes `SpawnAgentForkMode::FullHistory`. - `codex-rs/core/src/agent/control/spawn.rs` - `AgentControl::spawn_forked_thread` flushes the parent and reads the stored thread with `include_history: true`. - It uses `parent_history.items` as the forked rollout items. - The fork filter retains `RolloutItem::Compacted`. - The inspected `Compacted` records contain almost all of the affected bytes. - `codex-rs/core/src/session/mod.rs` - The `InitialHistory::Forked` branch in `record_initial_history` persists the inherited rollout items. - The code comment says: `If persisting, persist all rollout items as-is (the store filters).` - `codex-rs/core/src/compact.rs` - Compaction creates a `CompactedItem` with `replacement_history: Some(new_history.clone())`. - `codex-rs/core/src/session/mod.rs` - `replace_compacted_history` also persists a `CompactedItem` containing a cloned replacement history. - `codex-rs/rollout/src/recorder.rs` - `JsonlWriter::write_rollout_item` assigns a new timestamp, serializes the item with `serde_json::to_string`, and writes it to the child JSONL. - `codex-rs/app-server/README.md` - `thread/fork` is documented as creating a new thread by copying stored history. Questions that may help confirm whether the observed persistence is intentional: - Is a subagent fork expected to persist every historical `Compacted` record from the source rollout? - Is each earlier `replacement_history` expected to remain independently serialized after later compactions supersede it? - Is inline base64 image data expected to be repeated across every compaction snapshot and every full-history child fork? - Is there an intended upper bound for inherited persisted bytes when spawning a subagent? - Should proactive Ultra subagents have the same persistence behavior as an explicit user-created full thread fork? I can provide additional sanitized structural evidence if needed, including record-size distributions, parent/child metadata relationships, payload hash comparisons, compaction counts, and encoded image lengths. I cannot attach the complete affected rollouts because they are individually up to approximately 1.9 GB and contain private conversation and image data.", "url": "https://github.com/openai/codex/issues/34268", "createdAt": "2026-07-20T05:44:49Z", "updatedAt": "2026-08-13T12:46:17Z", "timestamp": "2026-08-13T12:46:17Z", "metrics": { "reactions": 6, "comments": 7 }, "labels": [ "bug", "context", "app", "subagent", "session" ], "author": "gonzalolarralde", "state": "open", "assignees": [] }, "evidenceUrl": "https://github.com/openai/codex/issues/34268", "pageUrl": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-2e1ff8006308" } ] }