v0.15.1

Fixed

• Thread-keyed libraries are now safe inside SDK callbacks. The SDK internally hops to a plain thread at every user-callback boundary — blocks passed to ClaudeAgentSDK.query / Client#receive_messages, SDK MCP tool handlers, hooks, permission callbacks, and observer methods — so the async gem's Fiber scheduler is no longer visible to user code. Previously, any library that keys state on Thread.current (ActiveRecord and every DB driver keyed by thread — pg, mysql2, sqlite3 — plus per-thread HTTP/cache pools, request stores, etc.) could be corrupted by the scheduler interleaving two fibers onto one checked-out connection. Rails/Sidekiq/Kamal consumers no longer need a caller-side wrapper to avoid this. See the "Thread-keyed libraries are safe inside SDK callbacks" subsection under Rails Integration in the README.

Changed

• Callbacks run on a plain thread, not inside Async::Task. Fiber-specific primitives (e.g. Async::Task.current.sleep, Async::Task.current.async { ... }) are no longer available inside tool handlers, hooks, permission callbacks, message blocks, or observers. Callbacks that want cooperative concurrency can open their own Async { } block. In practice callbacks do ordinary Ruby work and return a value, so this rarely affects real code.

Migration for consumers

Any project carrying a FiberSafeDb.run { ... } (or equivalent Thread.new { AR op }.value) wrapper inside SDK callbacks can delete it and call the ORM directly. Top-level Thread.new { Async { ... } } wrappers used to isolate the whole SDK call are still fine; they no longer do anything useful, but they don't hurt either.

What's changed

• #22 fix(async): contain Fiber scheduler inside the SDK — @chagel
• #24 Move OTel dev gems into optional Bundler group — @ya-luotao

Full Changelog: v0.15.0...v0.15.1

---

gem install claude-agent-sdk -v 0.15.1