Developer Tools on Margrop Blog

Windows Finally Gets Native Linux Commands: Microsoft Coreutils Replaces WSL, Cygwin, and Git Bash

Sat, 27 Jun 2026 08:00:00 +0800

Let me ask you something:

Have you ever tried to grep a log file in Windows Terminal, only to be told that grep is not a recognized command? Tried to use find to locate files, only to discover that Windows’ find is a completely different beast from Linux’s find? Written a cross-platform script that works perfectly on Linux, then falls apart the moment it touches Windows?

It’s not your fault. It’s the “Berlin Wall” between Windows and Linux command lines.

The good news? Microsoft just tore that wall down. In late 2025, Microsoft open-sourced coreutils on GitHub — a native Windows port of the essential Linux command set. No WSL. No Cygwin. No Git Bash. Just one winget install command, and your Windows terminal suddenly speaks fluent ls, grep, sed, and awk.

Your Mac App Is Not Broken: Gatekeeper May Just Distrust an Unsigned Tool

Mon, 01 Jun 2026 07:35:00 +0800

The short version

When a macOS utility refuses to launch after being downloaded, the first conclusion should not be “the app is broken.” A very common cause is a combination of two facts: the app still has the com.apple.quarantine extended attribute that marks it as downloaded from the internet, and the app bundle does not have a usable signature that Gatekeeper can trust. For first launch, “downloaded from the web + no usable signature” is enough for macOS to block it.

For a tool whose source you understand and trust, the smallest local repair is straightforward: inspect the quarantine attribute, verify the signing state, apply a local ad-hoc signature to that one app bundle, remove quarantine from that one app, and then verify the result. The point is not to turn off macOS security globally. The point is to fix one known local tool while keeping the safety boundary clear.

This post is based on a real local troubleshooting session, but all private details have been removed. There are no real internal addresses, usernames, tokens, private download locations, hostnames, or machine-specific paths. The examples use placeholders such as /Applications/<App>.app and <App>. The goal is to share a repeatable diagnostic method, not to expose an environment.

Claude Code Upgrade Broke Every Model? Before You Rotate Keys, Check the Compatibility Gateway

Fri, 29 May 2026 15:30:00 +0800

The short version

After a Claude Code upgrade, every model call failed with the same error: API Error: 400 invalid params, chat content has invalid message role: system (2013). At first glance this looks like a bad API key, a dead model, an exhausted account, a broken proxy, or a provider-wide outage. The root cause was different: a newer Claude Code request shape crossed an Anthropic-compatible model gateway that had not caught up with the client-side protocol behavior. The gateway, or a downstream chat validation layer behind it, rejected a system role in a place where it did not expect one.

The practical fix was not to randomly reinstall things. I reproduced the failure with the smallest possible prompt, tested adjacent Claude Code versions, and found the last known good version. 2.1.150 returned OK; 2.1.154 and 2.1.156 reproduced the 400. Pinning the global Claude Code installation back to 2.1.150 restored the existing provider path.

This post is a troubleshooting write-up for a local Claude Code environment. The fix itself was small, but the incident is useful because it shows a pattern that is becoming common in AI agent tooling: the CLI, environment settings, model gateway, API compatibility layer, and actual model backend are often separate moving pieces. When one layer changes its request structure, the terminal may only show a vague 400.

All private details have been removed. This article does not include real internal addresses, usernames, tokens, private provider names, local absolute paths, or private service domains. Configuration examples use placeholders such as <PLACEHOLDER>, <MODEL_GATEWAY>, and <MODEL_NAME>. The goal is to document a reusable debugging method, not to expose a specific environment.

Do Not Waste Your Codex Quota Before the Reset: Meet Codex Reset Radar

Sun, 24 May 2026 08:10:00 +0800

The short version

Codex resets have recently become more important to watch. Sometimes the reset is part of the normal usage cycle. Sometimes it is a compensation reset after an incident. Sometimes it follows a fix for abnormal limit consumption. For heavy Codex users, the painful part is not that the quota resets. The painful part is discovering that you still had useful weekly quota left, but you did not use it before the reset overwrote the old window.

Codex Reset Radar is a small public dashboard that turns scattered public signals into a practical warning: if a Codex quota reset window is likely or already open, it tells you to use your remaining weekly quota on valuable work before it expires.

This article discusses only public pages, public status signals, and public references. It does not include private accounts, tokens, internal systems, private network details, or personal usage data. Any discussion of quota, reset windows, and early warnings is a user-side workflow analysis, not an official statement about OpenAI billing, subscription policy, or service guarantees.

Your MCP Config Was Fine. The Server Died Before the Handshake.

Sat, 23 May 2026 06:10:00 +0800

The short version

The misleading part of this incident was the surface error. Codex reported that an MCP client could not initialize and that the MCP server handshake failed. That naturally pushes you toward MCP configuration, JSON-RPC initialization, plugin settings, authentication, network transport, or stale tool caches. But the root cause was lower than the MCP protocol: one local MCP server binary was killed by the macOS dynamic linker before it could answer the initialize request. The client only saw a closed connection. The useful evidence was in the server stderr: dyld: Symbol not found, pointing at a missing Swift Concurrency runtime symbol.

In other words, MCP did not really get a chance to fail. The server process died first.

This article walks through a real troubleshooting pattern around Codex, MCP clients, and MCP servers. The failure looked like a protocol startup problem, but the root cause lived in a native macOS binary and its Swift runtime compatibility.

All private details have been removed. This article does not include real internal addresses, usernames, session IDs, full local paths, tokens, private repository names, or business system names. Paths use placeholders such as ~, <USER_HOME>, <PLUGIN_DIR>, and <PROJECT>. Log snippets keep only the technical fields needed to explain the diagnosis.

Codex 0.130 Removed /approvals? The Fix Is to Move Permissions to Startup Flags

Tue, 12 May 2026 18:50:00 +0800

The short version

If you upgraded to Codex 0.130.0 and noticed that the old /approvals habit no longer works, the practical fix is not to downgrade. Move the permission policy to launch time. Use --ask-for-approval to control when Codex asks, --sandbox to control what commands can touch, and reserve --dangerously-bypass-approvals-and-sandbox for environments that are already isolated outside Codex. The long flag can also be written directly as --yolo, which is easier to remember, easier to type, and more consistent with command habits from tools such as Gemini.

In other words, stop treating approval mode as an in-session toggle. Treat it as part of the way you start the agent.

This article only discusses public Codex CLI flags and generic workflows. It does not include real hostnames, internal addresses, usernames, tokens, private paths, or project names. Commands use placeholders such as <PROJECT> and <TASK>.