DEV Community: Akhyar Amarullah

Wrote my thought process on redesigning my tiny CLI tool. https://akhy.my.id/posts/fixing-nested-shells-ksw-kubeconfig-switcher/ #go #kubectl #unix

Akhyar Amarullah — Sun, 19 Oct 2025 05:28:52 +0000

akhy.my.id

Fixing Nested Shells in KSW Kubeconfig Switcher: My Thought Process

Akhyar Amarullah — Sat, 18 Oct 2025 05:32:00 +0000

ksw (Kubeconfig SWitcher) is a small CLI tool I built to help me work with multiple Kubernetes contexts across different terminal windows. It creates isolated shell sessions, each using a different context, so I can have one terminal connected to production and another to staging without them interfering with each other. I use it every day at work.

It's a tiny project. I don't know if anyone else is using it besides me, but I wanted to improve it anyway. When I started working on this refactor, I had one clear goal: make the process tree as flat as possible. The nested shell problem was bothering me, and I wanted to fix it, even if there were catches along the way.

The Nested Shell Problem

The original implementation spawned a subprocess for each ksw invocation:

you@machine$ ksw production
  └─ ksw process (waiting)
      └─ zsh
          $ ksw staging
            └─ ksw process (waiting)
                └─ zsh

Each switch added another level. The KSW_LEVEL environment variable tracked how deep you were. It worked, but it felt wrong. I wanted a flat process tree with minimal nesting.

First Attempt: Parent-Managed Switching

My first thought was: what if the child shell exits and delegates the switching to the parent ksw process? The parent could detect the exit, switch the context, and spawn a new shell.

I quickly abandoned this idea. It was too complex. Coordinating between parent and child, passing signals or exit codes to communicate the desired context, handling edge cases. The complexity wasn't worth it.

(Side note: I might revisit this inter-process delegation approach later just for the sake of it. It's an interesting problem even if the simpler solution works fine.)

Discovery: syscall.Exec

Then I found syscall.Exec(). Instead of spawning a subprocess, it replaces the current process entirely. The ksw process doesn't wait around, it becomes the shell.

// Replace ksw process with shell
if err := syscall.Exec(shell, []string{shell}, os.Environ()); err != nil {
    return fmt.Errorf("failed to exec shell: %w", err)
}
// This line never executes - ksw is gone

Great! Now the process tree looks like:

you@machine$ ksw production
  └─ zsh

But what about switching contexts? If you run ksw staging from within that shell:

you@machine$ ksw production
  └─ zsh
      $ ksw staging
        └─ zsh

Still nested, but shallower. No idle ksw processes sitting around at each level. All ksw processes get replaced by shells at the same depth. Better, but not quite there yet.

The Workaround: Shell exec Command

I realized you could use the shell's built-in exec command:

production$ exec ksw staging

This replaces the current shell process with ksw, which then replaces itself with a new shell for the staging context. No nesting, but requiring users to type exec ksw instead of just ksw felt clunky. Not a good experience.

The Breakthrough: In-Place Updates

Then it hit me: if the current shell is already in a ksw session, I don't need a new shell at all. Each ksw session uses an isolated temporary kubeconfig file, that's the whole point of ksw. Other terminals aren't affected.

So why not just update that temp file in place?

// In main.go - detect if already in a session
if os.Getenv("KSW_KUBECONFIG_ORIGINAL") != "" {
    return switchContext(contextName)
}

// switchContext overwrites the existing temp file
func switchContext(contextName string) error {
    kubeconfigOriginal := os.Getenv("KSW_KUBECONFIG_ORIGINAL")
    existingKubeconfig := os.Getenv("KSW_KUBECONFIG")

    b, err := generateKubeconfig(kubeconfigOriginal, contextName)
    if err != nil {
        return err
    }

    // Overwrite existing temp file with new context
    if err := os.WriteFile(existingKubeconfig, b, 0600); err != nil {
        return err
    }

    logf("switched to context %s", contextName)
    return nil
}

Since kubectl reads the KUBECONFIG environment variable on every invocation, it immediately sees the new context. No new process, no nesting, just an updated file.

Now the flow is:

you@machine$ ksw production
  └─ zsh (KUBECONFIG=/tmp/production.xyz.yaml)
      $ ksw staging        # Updates /tmp/production.xyz.yaml in-place
      $ kubectl get pods   # Reads the updated file, sees staging context

Same shell, same process, different context. Flat process tree achieved.

The Result

The combination of syscall.Exec() for initial sessions and in-place updates for context switching solved both problems (see the full implementation):

First time: ksw replaces itself with your shell, no idle process
Context switching: ksw updates the temp file and returns, no new shell, no nesting

The KSW_LEVEL tracking is gone. The nested shell problem is gone. The process tree stays flat.

Trade-offs

There's one trade-off: temp file cleanup now relies on the OS cleaning up /tmp. Previously, the ksw process could delete the temp file when the subprocess exited. In practice, this hasn't been an issue. The files are tiny (~1-2KB) and OS temp cleanup handles them fine.

What I Learned

Sometimes the best solution comes from realizing you don't need to do something at all. I was so focused on how to make process spawning better that I almost missed the obvious: when you're already in a ksw session, you don't need another process. Just update the file.

The syscall.Exec() change made the architecture cleaner, but the real win was recognizing that in-place updates were possible because of ksw's isolated temp file design. The solution was already there in the architecture. I just needed to see it.

Try It Out

If you work with multiple Kubernetes contexts, give ksw a try:

brew install chickenzord/tap/ksw
ksw my-context

Switch contexts as many times as you want, your process tree stays flat.

ksw is open source at github.com/chickenzord/ksw. The exec refactor was implemented in PR #19.

Vibe-Coding My First MCP Server

Akhyar Amarullah — Fri, 05 Sep 2025 09:00:00 +0000

I recently built my first Model Context Protocol (MCP) server, and honestly? I had no idea what I was doing. The whole thing was pure vibe-coding. Throw ideas at Claude, see what works, and somehow end up with working software. The result was linkding-mcp, and I'm surprised it actually works.

What Even Is MCP?

Model Context Protocol is Anthropic's way of letting AI assistants connect to external tools and data sources. Think of it as giving Claude access to your stuff. Instead of just chatting, it can actually work with your real data. When I heard about it, my first thought was "I want my bookmarks accessible to Claude."

I use Linkding for bookmark management as part of my self-hosted setup, and the idea of asking Claude "find that article about Go testing I bookmarked last month" seemed too good to pass up.

The Vibe-Coding Approach

I've been experimenting with what I call "vibe-coding." Basically, let AI do most of the heavy lifting while I provide direction and fix the issues. For this project, I took it to the extreme.

My process was basically:

Tell Claude "I want an MCP server for Linkding"
Paste the Linkding API docs from their website
Let Claude generate the entire Go client
Ask Claude to build the MCP server on top of that
Ask Claude to generate the GitHub workflow for CI/CD
Debug and iterate until it worked

No careful planning, no detailed design docs, just pure experimentation guided by AI.

The Magic Moment

What surprised me was watching Claude generate a complete Go client library just from reading Linkding's API documentation. I copy-pasted the docs from their website, and within minutes I had working code that could:

Authenticate with Linkding
Create and retrieve bookmarks
Search through my bookmark collection
Handle pagination and error cases

Then, even more impressively, Claude built an entire MCP server on top of that client. The server implements the MCP protocol, handles tool registration, and provides clean interfaces for bookmark operations.

What the Final Product Does

The linkding-mcp server gives Claude direct access to my Linkding bookmarks. I can now:

Search bookmarks : "Find bookmarks about Kubernetes monitoring"
Create bookmarks : "Bookmark this URL with these tags"
Get bookmark details : "Show me the details of that bookmark about MCP"

It's surprisingly useful. Instead of opening Linkding in a browser and manually searching, I just ask Claude. For someone who bookmarks everything but rarely organizes it properly, having AI help navigate my collection is really helpful.

The AI-Assisted Development Experience

This project made me realize how much AI has changed software development. I'm experienced with Go, but I've never built an MCP server before. In the old days, I would have spent hours reading specs, looking at examples, and carefully implementing each piece.

Instead, I described what I wanted and let Claude figure out the implementation details. When something didn't work, I'd paste the error and get a fix. When I wanted to add features, I'd describe them and get working code.

The ratio was probably 90% AI-generated code, 10% me providing direction and debugging. The whole thing took about 3 hours from inception to a fully working Docker image automatically built and pushed on GitHub releases. And the result serves its purpose well as an experiment.

Technical Surprises

A few things that surprised me during this experiment:

MCP is surprisingly straightforward - The protocol is well-designed and Claude understood it from the specs.

API client generation is magic - Feed API docs to AI and get working client code.

Error handling just worked - I expected to spend time debugging edge cases, but the generated code handled errors well from the start.

Performance was fine - No optimization needed, it just works fast enough for personal use.

What This Means for Development

This project has me thinking about the future of software development. When AI can generate working code from documentation and natural language descriptions, what does that mean for how we build things?

I'm not ready to vibe-code everything, but for exploratory projects and personal tools? It's pretty powerful. The barrier between "I wish this existed" and "I have working software" has basically disappeared.

The Code

The entire linkding-mcp server is on GitHub. Fair warning, it's mostly AI-generated code with minimal polishing. But it works, and that's what matters for a personal tool.

If you're using Linkding and want to try it out, the setup is straightforward. Just don't expect production-grade code, this was pure experimentation.

What's Next

This experience convinced me that MCP servers are worth exploring further. My next project was PortoSync (connecting Indonesian investment data to Claude), and I'm already thinking about what other data sources would be useful to connect.

The ability to give AI assistants access to your actual data, rather than just generic knowledge, opens up a lot of possibilities. And if AI can help build the connections themselves, the barrier to experimentation drops to basically zero.

Vibe-coding might not be the future of all software development, but for personal tools and rapid prototyping? It's pretty amazing.

KSW (Kubeconfig Switcher)

Akhyar Amarullah — Sat, 25 Nov 2023 11:34:00 +0000

A while ago I created and published my own CLI tool to switch Kubeconfig. I wrote it in Go and it's installable easily using Homebrew:

brew install chickenzord/tap/ksw

Project repo: https://github.com/chickenzord/ksw

How it works

When you run the command and pass the context's name:

ksw context-name

Try loading kubeconfig file from these locations:
1. Path set in KSW_KUBECONFIG_ORIGINAL (more on this below)
2. Path set in KUBECONFIG
3. Default location $HOME/.kube/config
Minify and flatten the config so it only contains clusters and users used by the specificed "context-name", then put it in a temp file
Start a new shell (same with the currently used) with KUBECONFIG set to the temp file
Additionally, these environment variables also set in the sub-shell:
- KSW_KUBECONFIG_ORIGINAL: To keep track of original kubeconfig file when starting recursive shells
- KSW_KUBECONFIG: Same value as KUBECONFIG
- KSW_ACTIVE: Always set to "true"
- KSW_SHELL: Path to the shell (e.g. /bin/zsh)
- KSW_LEVEL: Nesting level of the shell, starting at 1 when first running ksw
- KSW_CONTEXT: Kube context name used when running ksw

Features

Supports recursive shell (starting ksw shell within ksw shell)
Shows a built-in fuzzy finder (like fzf) when no contexts specified in the argument
No automatic indicator in prompt, use the provided environment variables to set it depending on your setup

Some thoughts on the reason

You might think why am I reinventing the wheel? Some tools solve the same problem already.

I want a Kubeconfig switcher that simple (as in Unix philosophy) and can integrate easily with my existing ZSH and Prezto setup without getting in the way. Must also be able to integrate with other Kubernetes tools without many changes.

Automating interactive shell input in Go

Akhyar Amarullah — Mon, 06 Jul 2020 05:08:00 +0000

Once every several weeks, I take a moment to review and optimize my daily workflow, identifying bottlenecks or repetitive tasks that can be automated. This time I’m trying to tackle one of most tedious task that I do a lot on daily basis: logging in to VPN using OTP sent via email.

Why?

Context-switching

I have several VPN profiles and need to switch back and forth between them at work. Opening email and hunting down OTP code for each VPN session really slow me down, especially in tight situation like when firefighting in an incident.

I know automating 2FA sounds like defeating it’s own very purpose, but I still do it anyway for convenience ~~and educational purpose~~. Let’s see how I’m doing it.

Analyze before automate

Most of the times, automating shell input can be as simple as:

echo 'y' | ./interactive-setup.sh

Or even better, keep sending y to the process’ stdin:

yes | ./interactive-setup.sh

Yes, “yes” is a standard unix command.

So, why can’t we just do something like this? (note that oathtool is a CLI tool for generating time-based OTP)

oathtool --totp --base64 OTPKEY | openfortivpn -c prod.cfg

It can’t be done because:

I don’t have the key used to generate the OTP
The new OTP generated EVERYTIME AFTER connection initiated
The generated OTP are only sent via email, there is no other way

Let’s see how openfortivpn command get invoked:

❯ sudo openfortivpn -c prod.cfg
INFO: Connected to gateway.
Two-factor authentication token:🔑

The server generates and sends the OTP via email right before prompting for it. Also because it gets regenerated for each connection attempt, wrong input will somehow “invalidate” the already sent OTP (i.e. after a typo and fail, you cannot simply reconnect and input the correct OTP from previous attempt).

My solution

I have looked at Unix’s Expect also its Go implementation by Google, but not interested in both. I decided to implement my own logic in Go for learning purpose.

The program will execute openfortivpn and automatically input the OTP from my email (via IMAP). I already set the filter in my Gmail account so all OTP emails will be automatically moved to dedicated label/folder named “OTP”.

Here’s the logic outline:

Spawn openfortivpn client in the background (let’s call it “the process”)
Forward process stdout to terminal while monitoring it for the input prompt (“Two-factor authentication token:” string)
When the prompt detected, run a function to fetch email and extract the OTP
Write the OTP to the process stdin, then send newline (like pressing Return)

It seems simple, but I learned quite a lot along the way. It taught me about how to interact with subprocess’s IO stream in Go, also how to properly use goroutines and channels (the hardest part of Go for me to understand).

Here’s the simplified code.

import (
    "bufio"
    "fmt"
    "io"
    "log"
    "os"
    "os/exec"
    "path/filepath"
    "strings"
)

func connect() {
    configFile := "prod.cfg"
    promptString := "Two-factor authentication token:"

    // Prepare command
    cmd := exec.Command("openfortivpn", "-c", configFile)
    stdout, err := cmd.StdoutPipe()
    if err != nil {
        log.Fatal(err)
    }
    stdin, err := cmd.StdinPipe()
    if err != nil {
        log.Fatal(err)
    }
    cmd.Stderr = os.Stderr

    // Start command
    if err := cmd.Start(); err != nil {
        log.Fatal(err)
    }
    defer cmd.Wait()

    // Wait for OTP prompt
    promptDetected := func(bytes []byte) bool {
        frags := strings.Split(string(bytes), "\n")
        if len(frags) == 0 {
            return false
        }

        last := frags[len(frags)-1]

        return strings.HasPrefix(last, promptString)
    }
    prompt := make(chan bool, 1)
    go func(ch chan<- bool) {
        scanner := bufio.NewScanner(stdout)
        scanner.Split(bufio.ScanBytes)

        buff := []byte{}
        for scanner.Scan() {
            bytes := scanner.Bytes()
            fmt.Print(string(bytes))
            buff = append(buff, bytes...)
            if promptDetected(buff) {
                ch <- true
            }
        }
    }(prompt)
    <-prompt

    fmt.Println("Getting OTP")
    otp, err := fetchOtpFromEmail() // delegate it to another function
    if err != nil {
        log.Fatal(err)
    }

    // Send input to the prompt
    io.WriteString(stdin, otp)
    io.WriteString(stdin, "\n")
}

The complete code is on my GitHub project. It’s usable and configurable for your own use.

Minimal Makefile to Run Java Projects

Akhyar Amarullah — Wed, 18 Dec 2019 08:12:00 +0000

Recently, a conversation with my SO reminded me about a piece of code I write long time ago. It was a college assignment on Data Structure course.

I immediately dug my email and found the project compressed in a RAR archive. The project was written using Java with NetBeans IDE default folder structure. There was no build configurtions like Maven, Ant, Makefile, or whatsoever. Only NetBeans project config and I don’t want to install it just for the sake of running the code.

After Googled a bit, I came with a quick and simple Makefile to run the code. Luckily there was no external dependencies to deal with.

SRC ?= src
DST ?= build/classes
MAIN ?= Main

.PHONY: clean compile run

clean:
    rm -f $$(find $(DST) -name *.class)

compile:
    mkdir -p $(DST)
    javac -d $(DST) $$(find $(SRC) -name *.java)

run:
    java -cp $(DST) $(MAIN)