[BUG] Claude conflates "kernel space" generically with Linux kernel space when discussing portability of bare-metal libraries

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?

Repro: Ask about smoltcp's placement (userspace vs kernel). Claude answers
"position-agnostic — runs in Linux userspace, in-kernel, or bare-metal" without
qualifying that "in-kernel" means bare-metal/custom kernels only, not Linux kernel.

Why wrong: Linux kernel networking is built around sk_buff, net_device, and the
socket layer — a non-negotiable ABI. smoltcp has no integration path. The only real
options on Linux are (a) userspace via TAP/DPDK/AF_XDP, or (b) a bridging .ko that
defeats the purpose by reintroducing sk_buff overhead. Claiming "runs in-kernel"
without this qualification is incorrect and wastes the user's clarification cycles.

Impact: In a systems-design conversation, imprecise portability claims lead the
user down wrong architectural paths before the error is caught.

Expected: Claude should qualify "kernel space" with which kernel, and proactively
note Linux's sk_buff/net_device constraint when recommending bare-metal libraries

What Should Happen?

Repro: Ask about smoltcp's placement (userspace vs kernel). Claude answers
"position-agnostic — runs in Linux userspace, in-kernel, or bare-metal" without
qualifying that "in-kernel" means bare-metal/custom kernels only, not Linux kernel.

Why wrong: Linux kernel networking is built around sk_buff, net_device, and the
socket layer — a non-negotiable ABI. smoltcp has no integration path. The only real
options on Linux are (a) userspace via TAP/DPDK/AF_XDP, or (b) a bridging .ko that
defeats the purpose by reintroducing sk_buff overhead. Claiming "runs in-kernel"
without this qualification is incorrect and wastes the user's clarification cycles.

Impact: In a systems-design conversation, imprecise portability claims lead the
user down wrong architectural paths before the error is caught.

Expected: Claude should qualify "kernel space" with which kernel, and proactively
note Linux's sk_buff/net_device constraint when recommending bare-metal libraries

Error Messages/Logs

Repro: Ask about smoltcp's placement (userspace vs kernel). Claude answers         
  "position-agnostic — runs in Linux userspace, in-kernel, or bare-metal" without    
  qualifying that "in-kernel" means bare-metal/custom kernels only, not Linux kernel.
                                                                                     
  Why wrong: Linux kernel networking is built around sk_buff, net_device, and the    
  socket layer — a non-negotiable ABI. smoltcp has no integration path. The only real
   options on Linux are (a) userspace via TAP/DPDK/AF_XDP, or (b) a bridging .ko that
   defeats the purpose by reintroducing sk_buff overhead. Claiming "runs in-kernel"
  without this qualification is incorrect and wastes the user's clarification cycles.

  Impact: In a systems-design conversation, imprecise portability claims lead the    
  user down wrong architectural paths before the error is caught.
                                                                                     
  Expected: Claude should qualify "kernel space" with which kernel, and proactively  
  note Linux's sk_buff/net_device constraint when recommending bare-metal libraries

Steps to Reproduce

Repro: Ask about smoltcp's placement (userspace vs kernel). Claude answers
"position-agnostic — runs in Linux userspace, in-kernel, or bare-metal" without
qualifying that "in-kernel" means bare-metal/custom kernels only, not Linux kernel.

Why wrong: Linux kernel networking is built around sk_buff, net_device, and the
socket layer — a non-negotiable ABI. smoltcp has no integration path. The only real
options on Linux are (a) userspace via TAP/DPDK/AF_XDP, or (b) a bridging .ko that
defeats the purpose by reintroducing sk_buff overhead. Claiming "runs in-kernel"
without this qualification is incorrect and wastes the user's clarification cycles.

Impact: In a systems-design conversation, imprecise portability claims lead the
user down wrong architectural paths before the error is caught.

Expected: Claude should qualify "kernel space" with which kernel, and proactively
note Linux's sk_buff/net_device constraint when recommending bare-metal libraries

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.114

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_