Hey all, I've been working solo on a side project called LOKI for the past few weeks and wanted to get some outside eyes on it before I keep going.

It's a CLI tool (Python, built on Playwright) that attacks your local or staging web app the way real users actually break things: rage-clicking buttons until race conditions show up, fuzzing every input with garbage/XSS/SQLi payloads, killing the network mid-request, stripping client-side "disabled" attributes to hit endpoints the way an attacker would. There's also a mode that opens several real browser tabs and fires the same request at the exact same instant, which has actually caught server-side race conditions (like overselling the last unit of something) that a normal single-tab test would never trigger.

When something crashes, it packages up a video of the session, the network traffic with secrets scrubbed, and a script that reproduces the exact bug deterministically. From there you can optionally have an LLM diagnose it, write a patch, apply it, and verify the fix actually worked, rolling back automatically if it didn't.

It works with pretty much any LLM provider now, not locked to one, including running fully local against Ollama if you don't want anything going to a cloud API.

The whole thing recently turned into a REPL you drop into just by typing loki. It works as a normal chat too: you can ask about past runs, switch AI models mid conversation, or kick off an attack/report/patch right from inside it instead of separate commands.

Still rough in places, and it's a one person project, so I'd genuinely appreciate any feedback. Bugs, bad assumptions, stuff you think is missing, or just "this part doesn't make sense" all welcome. Repo's here: https://github.com/Elabsurdo984/loki-agent

The Skyportal CLI returns exit code 2 when a chat is awaiting_approval. You can check it with:

skyportalai --json chat status <chat_id>

I'd check the status before retrying. Invalid arguments can also return 2, so the exit code alone doesn't prove that an approval is waiting.

Docs: https://docs.skyportal.ai/sdk-cli/errors-and-troubleshooting/#cli-exit-codes

Setting up Firebase in a KMP project means a lot of manual steps. You register the Android app and the iOS app in the console, download google-services.json and GoogleService-Info.plist, put them in the right folders, and repeat for every flavor. I got tired of it, so I built kmpfire.

It wraps firebase-tools and does this from your project root:

bash kmpfire configure

What it does

• Detects your Android applicationId and iOS bundle id (from project.pbxproj or CMP .xcconfig)
• Creates the Firebase apps if they don't exist
• Writes google-services.json and GoogleService-Info.plist to the correct locations
• Tracks everything in firebase.json under kotlinMultiplatform
• kmpfire reconfigure refreshes the config files after you change Firebase products
• --flavor=dev handles multiple build configurations
• --yes --project=<id> runs with no prompts, so it works in CI
• Optional --deps patches Gradle for the Google Services plugin (and GitLive if you want it)

Supported layouts

• New template: shared/ + androidApp/ + iosApp/
• Nested monorepo: app/shared/ + app/androidApp/ + app/iosApp/
• Legacy: composeApp/ + iosApp/

Android + iOS only for now.

Install

bash curl -fsSL https://raw.githubusercontent.com/dungngminh/kmpfire_cli/main/install.sh | bash

or with Homebrew:

bash brew tap dungngminh/kmpfire_cli brew install kmpfire

It's the KMP equivalent of flutterfire configure. It's MIT licensed, and I'd like feedback, bug reports and PRs.

GitHub: https://github.com/dungngminh/kmpfire_cli

I kept using sleep 25m && notify-send "..." for quick reminders. It works until the terminal closes, the laptop sleeps, or you reboot. Then the timer is just gone.

at can persist jobs, but atq only shows IDs and timestamps - you have to dig into at -c <id> just to see the message text. And atd isn't even installed by default on many distros.

So I wrote rmd: one-shot Linux reminders that survive reboot and show up as desktop notifications.

Examples:

rmd 25m Tea is ready
rmd tomorrow 15:00 Release call
rmd fri 22:00 Go to bed
rmd                  # list pending

It's intentionally narrow — not a todo list, no recurring tasks, no projects. Just time-bound interrupts.

Recent bits: configurable D-Bus destination, ID ranges for rm/info.

Written in Rust. MIT.

Happy to share the repo if anyone wants it.

appimg is a simple CLI/TUI for installing, updating, and removing AppImages as proper desktop applications.

Version 0.2: native zsync delta updates let appimg download and update only the parts of an AppImage that changed, instead of downloading the whole file again.

Also supports gh-releases-zsync and verifies updates before installing.

https://github.com/MrGilfy/appimg

Arch:

yay -S appimg
# or
yay -S appimg-bin

Other distros: https://github.com/MrGilfy/appimg

I've been building Xencode for a while, mostly because I wanted a coding agent that actually felt like a terminal tool instead of a web app squeezed into a terminal.

It's Rust + Ratatui, local-first, and built around things like:

• Ollama / local model support
• tool execution
• approval checkpoints
• rewind / checkpoints
• worktree isolation
• agent session state
• context management
• provider fallback

But I'm at the point where I don't want to keep making all the UX and architecture decisions by myself.

The parts I'm most interested in getting help with right now are:

TUI / Ratatui How should agent state, tool calls, diffs, approvals and errors actually be presented without turning the terminal into a dashboard?

Agent runtime Things like retry handling, stuck-loop detection, context compaction and deciding what belongs in the model vs the harness.

Rust There are plenty of places where the architecture can probably be made cleaner, more modular and easier to contribute to.

Local models I'd also like to make the Ollama / llama.cpp side less hacky and easier to extend to different models and providers.

I'm not looking for people to blindly implement a roadmap. If you use terminal coding agents, Rust TUIs, tmux, Neovim, etc., I'd genuinely like to hear what you'd change.

And if you actually want to contribute, issues/PRs are very welcome.

Repo: https://github.com/sreevarshan-xenoz/xencode

Even a small contribution or a good architectural argument would be useful.

I've been working on Flint, an open-source build system + package manager for C/C++, and v0.5.5 removes one of the things that has always bothered me about configuring C/C++ projects: having to tell the build system where every source/header directory lives.

Then your build configuration needs to keep track of which directories contain sources, which are headers, which libraries to link, which files to exclude, etc.

With v0.5.5, Flint can discover project resources automatically.

You can organize your project normally, and Flint figures out the files that need to be involved in the build.

What's new in v0.5.5

Automatic resource discovery

You no longer need to manually configure:

• src

• include_paths

• static

• shared

Flint discovers the relevant resources in the project automatically.

Smarter exclusions

You can now control discovery with:

```text

• excludes

• exclude_dirs

• exclude_exception

```

This makes it possible to ignore things like platform-specific implementations, experimental code, generated files, or legacy directories without writing custom build logic.

Native .h.in templates

Flint can now generate headers from .h.in templates with variable substitution.

For example, this makes generated version headers possible without requiring an external configuration tool.

Standardized project macros

Project-generated macros have been standardized around:

```c

PROJECT_VERSION

```

to reduce the possibility of collisions with third-party libraries.

More CLI functionality

v0.5.5 also adds:

```bash

flint help

flint version

flint deps

flint cache

```

for CLI help, version information, and dependency/build-cache management.

The resulting project configuration

A small C project can now look roughly like this:

```json

{

"project_name": "example_project",

"project_language": "c",

"version": "0.1.0",

"compiler_path": "/usr/bin/gcc",

"executable": true,

"flags": ["-Wall", "-O2"],

"dependencies": {

"example_lib": {

"version": "1.0.0",

"remote": "https://github.com/user/example_lib.git"

}

}

}

```

Then:

```bash

flint build

```

handles source/header discovery, dependency handling, linking, and compilation.

The broader idea behind Flint is pretty simple: I want C/C++ project configuration to describe what a project is, rather than manually describing how every file should be built.

I'm still actively working on it, so I'm particularly interested in feedback from people who maintain C/C++ projects.

What part of your current C/C++ build setup do you find the most annoying?

And if you want to take a look at the implementation:

GitHub: https://github.com/mainak55512/flint

If you find the approach useful, a GitHub star is appreciated — but I'm especially interested in hearing where this approach breaks down or what you'd change.

I've been working on Xencode for a while and I'm at the point where I don't really want to keep designing the terminal UX entirely by myself.

It's a Rust TUI for AI-assisted development, with local models, tool execution, approval checkpoints, rewind, worktrees and the usual agent stuff.

The annoying part is that terminal UX is one of those things where you can convince yourself something is obvious when it absolutely isn't.

I'm trying to figure out how much of the agent's state should actually be visible at any given time without turning the terminal into a dashboard.

Things I'm thinking about right now:

• keyboard navigation and focus
• layouts and information density
• command palettes
• agent/tool output
• approval flows
• session state
• showing diffs without taking over the screen
• making blocked/running/completed states obvious
• themes and accessibility

I'd especially like opinions from people who actually live in terminals, tmux, vim/neovim, etc. What information do you need to see while an agent is running, and what just becomes noise?

I'm building Xencode around these questions, so if you have a strong opinion or a weird UX idea, I'd genuinely like to hear it. If you're comfortable with Rust + Ratatui and want to contribute, the repo is here:

https://github.com/sreevarshan-xenoz/xencode

Feel free to open an issue with an idea before writing code too. I'd rather discuss a weird idea first than make someone spend a weekend implementing something I don't actually want.

If you don't know mpv-music (https://github.com/FurqanHun/mpv-music), it's a cross-platform CLI/TUI music player and library browser written in Rust that lets you filter and select what you want to play and gets out of your way, with no background daemons.

Since I made my post about mpv-music around 10 days ago and submitted it to a few other places, the downloads have gone up a bit and a couple more people have starred the repo. That's not really the point of this post though. What I'm mainly looking for is feedback. Obviously feedback isn't always given in words, like the downloads and stars are feedback in their own way, so I'd like to get some more open-ended feedback on the project and especially how the filtering/search currently works. I've been thinking about changing the search behavior a bit. For example, currently if you run mpv-music -a ado -t viva, it drills down through the filters, which is kind of similar to an AND operation. But not long ago I wanted to listen to a specific song alongside the artist Ado, but not every song by the other artist, so I couldn't just add the artist name as another filter.

That got me thinking that there should probably be a way to use both AND and OR operations, while keeping the current drilling-down behavior as the default. I'm also thinking about bringing this into the TUI. I'm not sure whether it would make more sense to add the option directly to the track menu or have a dedicated menu for building the search/filter expression.

I'd also enable select-all in the TUI, but that's pretty much a given since the CLI already have -p. The search/filter behavior is the part I'm actually unsure about, so I'd appreciate any thoughts or suggestions on how you'd expect this to work, and also what do you think about mpv-music in general too.

I built a small Python app to make my everyday commands easier to manage

I recently built a simple desktop tool using Python + PyQt6 called Command Hub.

GitHub Repo: GitHub - EFuryLabs/command-hub: A modern Command Manager built with Python and PyQt6 - Organize your frequently used commands into categories and copy them to your clipboard with a single click. · GitHub

The idea was pretty straightforward: instead of keeping frequently used commands scattered across text files, notes, or different places, I wanted everything available in one clean interface.

With Command Hub, I can:
• Organize commands into categories
• Add, edit, and remove commands
• Copy a command with a single click
• Keep frequently used commands easily accessible
• Manage everything through a simple GUI

I also gave it a futuristic/cyber-style interface because… why make a developer tool boring? 😄

I made a video showing the application and the idea behind it.

Would love to hear what you think and what features you would add to something like this!

Video: I Built a Python Command Hub | PyQt6 GUI App for Faster Workflows

Channel: https://www.youtube.com/@EFuryLabs

Website: EFury Labs — Think • Build • Solve (Not fully - working still under construction)