[BUG] False-positive AUP block on z/OS HLASM development, Opus 4.7, mid-session regression

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?

Max plan, Opus 4.7, working day on z/Architecture assembly and C, session was stable for ~a day then degraded, error persists across retries, fallback to older Sonnet suggested by the error message isn't viable for the work. I have no idea what trigger things to go bad. We had been slinging C and assembly code all day. I have included as much as the session that was left in my WSL window. Claude version: 2.1.119 (Claude Code). I've submitted a bug report to support@anthropic.com and "Fin" the agent said my conversation id was 215474044213289. Is this a case number?

claude_session.txt

What Should Happen?

Tell me how to tell Claude Opus that people who program in mixed C and Assembly language on ZOS are not nefarious actors.

Error Messages/Logs

Here's a fragment of the larger attached session copy:


● Bash(echo "=== local file bytes / encoding ==="; file /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c; wc -l -c
      /home/joede/git2026/zoweclang/zowe-common-…)
  ⎿  === local file bytes / encoding ===
     /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c: C source, Unicode text, UTF-8 text
       48 1485 /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c
     … +6 lines (ctrl+o to expand)

  Called zos 2 times (ctrl+o to expand)

● Let me isolate whether it's upload-specific by creating a minimal file DIRECTLY on z/OS (not via upload) and compiling it.

  Called zos 2 times (ctrl+o to expand)

● Upload-specific issue. Native-created file compiles fine; uploaded file can't be opened by ibm-clang64 despite looking normal. Let me
  compare the upload-created files against the native-created one at byte level.

● Calling zos… (ctrl+o to expand)

✻ Building configmgr with ibm-clang64… (1m 22s · ↑ 4.0k tokens · thought for 8s)
  ⎿  ✔ Fetch + checkout feature branch on z/OS
     ◼ Run build_cmgr_clang.sh zos on z/OS
     ◻ Functional test configmgr on z/OS
     ◻ Fix em-dash chars in source comments


  ❯ /effort
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ Press up to edit queued messages
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  esc to interrupt · ctrl+t to hide tasks


● The EDC5122I Input/output error is the same charsets.c-style I/O failure — probably a file-tagging issue from my upload. Let me check the
  tag.

  Called zos 5 times (ctrl+o to expand)

❯ If you make a file locally in UTF8 and you use zos_upload_files all should go well.

● Taking you at your word — UTF-8 local + zos_upload_files should be fine. So this I/O error is probably transient or something specific. Two
  things I'll do:

  1. Fix the RC detection in the build script — | tee ... was eating the compiler exit code, so the rc=0 was misleading. Using PIPESTATUS[0].
  2. Suggest a fresh re-upload, since I don't see anything wrong with the local file and your observation is that the upload-to-compile path
  normally works.

● Write(build/build_hlasm_mini.sh)
  ⎿  Added 3 lines, removed 4 lines
       9  #
      10  # Output: build/hlasm_mini.o + build/hlasm_mini.log
      11
      12 -set -e
      13 -
      12  V=${1:-1}
      13
      14  BUILD_DIR=$(cd "$(dirname "$0")" && pwd)
     ...
      31    -ferror-limit=100                      \
      32    "$SRC" 2>&1 | tee "$LOG"
      33
      36 -RC=$?
      34 +# Use PIPESTATUS[0] to capture clang's exit code, not tee's.
      35 +RC=${PIPESTATUS[0]:-$?}
      36  echo "---"
      38 -echo "rc=$RC  obj=$OBJ  log=$LOG"
      37 +echo "compiler rc=$RC  obj=$OBJ  log=$LOG"

  Called zos (ctrl+o to expand)

● Re-uploaded both. Try ./build_hlasm_mini.sh 1 again — the fresh upload may fix whatever the I/O error was, and the script's exit-code
  reporting now shows the real compiler rc.

✻ Churned for 2m 18s

❯ if you use zos_exec to run the build script, what do you see?

  Called zos (ctrl+o to expand)

● Same EDC5122I I/O error as Joe saw. And the rc=0 is spurious — PIPESTATUS doesn't work under /bin/sh. Let me look at the local file for
  anything unusual.

● Bash(echo "=== local file bytes / encoding ==="; file /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c; wc -l -c
      /home/joede/git2026/zoweclang/zowe-common-…)
  ⎿  === local file bytes / encoding ===
     /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c: C source, Unicode text, UTF-8 text
       48 1485 /home/joede/git2026/zoweclang/zowe-common-c/c/hlasm_mini.c
     … +6 lines (ctrl+o to expand)

  Called zos 2 times (ctrl+o to expand)

● Let me isolate whether it's upload-specific by creating a minimal file DIRECTLY on z/OS (not via upload) and compiling it.

  Called zos 2 times (ctrl+o to expand)

● Upload-specific issue. Native-created file compiles fine; uploaded file can't be opened by ibm-clang64 despite looking normal. Let me
  compare the upload-created files against the native-created one at byte level.

  Called zos (ctrl+o to expand)
  ⎿  API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy
     (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist
      with a different task. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models.

Steps to Reproduce

I was working on fixing bugs in a legitimate project. I was on a session using the Claude CLI in Windows Subsystem For Linux. I am part of the zowe.org (Open Mainframe Project) part of the Linux Foundation. I am working on some nasty bugs in upgrading the C compiler and its use of embedded assembler code. Nothing really different that what kernel or device driver people might do. Anyway after about 6-12 hours of slogging away on the bug I go into a loop with the:

_⎿ API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy
(https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist
with a different task. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models._

For details sake we were working exactly on this file: https://github.com/zowe/zowe-common-c/blob/v3.x/staging/c/recovery.c, and trying to figure out how to get the new IBM clang compiler (ibm-clang64) to accept certain __asm() constructs that worked in older, more proprietary IBM c compilers. I just cannot come up with a theory of what the trigger could have been. I've included a partial transcript.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

4.7

Claude Code Version

2.1.119

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_