Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

GPT-6 Astra: HTTP 422 cyber-risk rejection during local heap-OOM debugging

Đang mở
#4,912 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js
Lĩnh vực
backend, cli

Hướng nghiên cứu

Start with the CLI session logs, especially the session.error entries containing errorType: "query" and statusCode: 422, and compare them with the reported HTTP 500 retry behavior. The issue has no named source file, test, or minimal reproducer; done would mean clearly distinguishing this policy rejection from a normal assistant response and providing a reporting path for suspected false positives.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

triage

Type: Bug

Copilot CLI Version: 1.0.84-5
OS Version: Windows 11 x64
Model: gpt-6-astra

Summary

While debugging Copilot CLI's own JavaScript heap OOM, a request to gpt-6-astra failed with HTTP 422 and a message telling me to join Trusted Access for Cyber.

The task was local crash reproduction and memory analysis, not security testing.

Steps to Reproduce

No minimal prompt or deterministic reproducer yet. The observed workflow was:

  1. Use an interactive CLI session with gpt-6-astra.
  2. Analyse local Node.js OOM reports and work on a local crash reproducer.
  3. A subsequent model request fails with the error below.
Actual Behaviour

The CLI reports:

Execution failed: 422 This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber (Request ID: ...)

The session log records session.error, errorType: "query" and statusCode: 422. The request fails instead of returning an answer.

The error does not identify which part of the conversation was flagged.

Frequency and model correlation

I attributed every provider error across 1,061 local CLI session logs (4.83 GiB, 2026-03-16 to 2026-09-20) to whichever model was active at the time. Every cyber-risk 422 in six months of history landed on a GPT model:

Model Turns cyber-risk 422
gpt-6-astra 14,439 10
gpt-5.6-sol 5,390 2
claude-opus-5 39,623 0
claude-opus-4.8 6,558 0
gemini-3.8-flash 189 0
claude-opus-4.6-1m 120 0

That is 12 rejections in 19,855 GPT turns (0.06%) and none in 46,302 Claude turns, from one account doing the same kind of work. The two gpt-5.6-sol hits were on 2026-09-04 in an unrelated session, so this is not specific to one model version or one conversation.

The one cyber-risk rejection that did land on claude-opus-5 is also the more interesting one: it came back as HTTP 500 and was retried 5 times before failing. Every GPT rejection came back as 422 and was fatal on the first attempt, with no retry. Same message text, different status code, different retry treatment.

Counts are the errors surfaced to the session. Retries within a single failed call are not recorded individually, so the true request count is higher.

Attempted reduction

I couldn't reproduce the 422 with isolated text prompts on gpt-6-astra.

Loaded CLI payload Control completed Crash-debugging prompts completed HTTP 422 Tool calls
1.0.84-5 1/1 4/4 0 0
1.0.87-0 1/1 4/4 0 0

These included the original short message, "Another copliot heap issue just now", and synthetic Node.js OOM diagnostics. Each request used fresh CLI state with tools and custom instructions disabled. Loaded builds were verified from native-module paths.

The original long conversation and attachments were not replayed. These results only show that the short prompts did not trigger the rejection; they do not establish that the original incident is fixed. I still don't have a minimal failing prompt.

Expected Behaviour

Routine local crash debugging should not require security-work authorisation. A suspected false positive should have a clear reporting path, with the CLI distinguishing a service policy rejection from a normal assistant response.

Notes
  • I still have not reduced this to a standalone prompt.
  • The log confirms an HTTP 422 policy response, not which backend component made the decision or which input triggered it.
  • This is separate from the stream-truncation failures: the service returned an explicit rejection here.
Impact

An ordinary debugging request is blocked with a security-work message that does not explain what needs correcting.

Ngôn ngữ chính
Shell
Star
11.2k
Fork
1.9k
Merge trung bình
14 giờ 16 phút
Pull request đã merge (30 ngày)
6

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của github/copilot-cli

Tất cả issue của github/copilot-cli

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.