Blog @ Codonomics

When optimizing your development environment on Windows, you might encounter a frustrating "silent failure" where Docker containers appear to run but remain unreachable via their assigned ports. This conflict typically stems from how WSL2 and Docker Desktop negotiate network traffic. (I had been through this when I tried to set-up my development environment for ReactNative/Expo application in Docker container.) The Architecture: Mirrored vs. NAT By default, WSL2 uses Network Address Translation (NAT). In this mode, WSL2 lives behind a virtual switch with its own IP address. While reliable, it adds a layer of complexity for local networking. (Spoiler Alert: I resorted to this legacy convention for reliability reasons, at the time of this writing having latest stable version of Docker Desktop). Reasons: Good default for general, isolated development; avoids complex network setup. Downsides: Requires port forwarding to access localhost services from Windows; VPNs can brea...

Fix for Ollama Issue on Windows 11 where it doesn't connect

If you are using Ollama on Windows 11 machine and are encountering the error below: Error: Head "http://0.0.0.0:11434/": read tcp 127.0.0.1:61593->127.0.0.1:11434: wsarecv: An existing connection was forcibly closed by the remote host. Then it is likely that your previous force closure of Ollama left an abandoned process connecting to the said port - 11434. Unfortunately, at least in my case, this process didn't vanish even when I restarted the system that sure troubled me much. The fix that worked for me was to identify the process-id of that rogue/abandoned process and kill it by its process-id. This is done in Windows Powershell (having admin privileges) like below: Find process-id using the command ` Get-NetTCPConnection -LocalPort <port_number> | Select-Object -ExpandProperty OwningProcess ` where you replace the <port_number> with actual port (11434 in this case) and this command outputs the PID of the process. ...

Break Claude Code's Walled Garden To Use Any LLM

Claude Code (CC) is brilliant revolutionary tool, but it’s a walled garden - it is locked to Anthropic’s API. You are forced to use Anthropic’s models, at Anthropic’s prices, with Anthropic’s context limits. What if you want to use the massive 1M token context of Gemini 2.5 Pro? What if you want to run simple background tasks on a free, local model using Ollama? What if you need the specific reasoning style of DeepSeek? You shouldn't have to choose between a great coding assistant and your preferred AI infrastructure. Claude Code is designed to be the ultimate terminal-based agent, but its native configuration is hardwired for Anthropic’s API. However, like most professional CLI tools, it respects specific environment variables that allow you to configure its "brain" to any Anthropic's listed endpoints. We leverage this configuration option to jail-break from its vendor lock-in. The key to unlocking Claude Code lies in 2 primary environment variables: ANTHR...

Beyond Grep: Master ripgrep Performance in Claude Code

If you’ve ever wondered why modern AI coding agents like Claude Code (CC) feel so "aware" of your codebase, the secret often lies in a small, incredibly fast tool called ripgrep (rg) . ripgrep is a line-oriented search tool that recursively searches your current directory for a regex pattern. It combines the raw speed of C with the safety of Rust. It is faster than almost every other search tool because it is built on top of Rust’s regex engine, which uses finite automata, SIMD, and aggressive literal optimizations to make searching very fast. It is the engine that allows Claude to "read" your project in milliseconds. Most importantly for developers, ripgrep respects your `.gitignore` . It won't waste time searching through your `node_modules` , `.git` , or build artifacts, ensuring that Claude only sees the code that actually matters. There are 3 distinct ways Claude can utilize this tool? Depending on your codebase size ...

Connect to Ollama in Windows host from Docker container

It is one things to connect to services running in Docker container from Window host and altogether another thing to do the reverse of it. Attempting to connect to Ollama in Windows host from Docker container is that just and this post is a recipe to solve this problem. To connect a Docker container to an Ollama instance running natively on a Windows host, you must address two main hurdles: allowing the Windows service to accept external (non-local) traffic and using the correct address from within Docker. 1. Configure Ollama to Listen on All Interfaces By default, Ollama service running in Windows host only listens on 127.0.0.1, which prevents Docker containers from reaching it. You will have to change it to 0.0.0.0 to get it working and to do so follow the below steps: Quit Ollama service that is currently running. Set Environment Variable in your Windows: OLLAMA_HOST=0.0.0.0 Restart Ollama service. 2. Connect from Docker using the Special DNS Name Docker Desktop fo...

My Past Speaking Engagements

Powered by Blogger