It seems like tsx is a wrapper around tsc for easy compile+run workflow.

tsz seems to be a compiler, a replacement for tsc

Seems like tsx is a wrapper around esbuild, not tsc.

Ok, what about having tools be discoverable from the environment, similar to how $PATH works in POSIX?

There could be an env var $AGENT_TOOLS, a string of paths delimited by `:` and tools would be discovered as some specific format of file. Maybe a JSON that contains tool name, list of parameters and the command to run it.

This is essentially decoupling tools from the agent, allowing more customization and per-project environments. It does require shipping and installing more binaries, one for each tool probably.

This is one of the approaches im considering for my own, Roder.

The approach mostly being communicating over json rpc which has become the standard for MCP so it makes it more approachable to agent developers.

Obviously its very much NOT mcp, its a low level events based rpc system for registering capabilities and extending low level primitives of the agnet itself not the model

The Hermes agent (Python) follows something similar; it defines a HOME dir and enumerates plugins and memory extensions present there.

https://github.com/nousresearch/hermes-agent

Functionally, it fits more in the openclaw space than pi-agent.

I understand the concept, but I don't get what's the advantage over adding in the prompt instructions to use a specific bash command for a specific task, acting as a "custom tool".

The harness clamps what the agent can do. `bash` allows full code execution; a dedicated `mvn` tool might only allow `mvn compile` but not `mvn spring-boot:run`. You could probably implement this with an `allow` list attached to your `bash` tool, but by doing it this way, you can enhance the outputs or perform mandatory checks too.

For instance, Claude likes to run little Python scripts; reviewing them is tedious. Removing `bash` and adding a `python` tool would allow the harness to pre-review and grep for common harmful patterns, or run the `python` script in a `krunvm` or `muvm` to isolate it, etc. This review/isolation would be handled programatically as it's part of the harness; leaving the agent to choose what to do as a skill means the agent can conveniently forget to enforce its own checks.

Good point. There might be a small advantage if one does not want to give bash access. But general answer to "how do add custom tools like we can in pi" is "you don't". Keep it simple.

For converting HTTP URLs into interactive images of the webpage.

In other words: an internet browser.

CapNProto RPC protocol

Because some auth provider recommended it as the only app to use. While it is a good app, it does backup into Drive.

While it’s not a perfect solution, you can export and backup your data with QR codes, so you can back it up without cloud.

Is this useful if I am using pi coding agent? It can swicth between models mid session?

Forgejo is also OSS, so you can easily migrate git and issues and prs and everything to your own hosted instance, if codeberg proves untrustworthy. Which I can't on github.

Could the title say "process to install non-curated Android apps"? "Sideload" and "unverified" imply that the collection of centrally approved apps is the default way to install software.

Or maybe it is and android's promises about openness are dead.

The `:` prefix is an interesting choice. I don't fully understand when it is needed. It seems to always be used at the beginning of the query. But why is it not used before WHERE?

The : prefix marks OmniQL commands, the action you want to perform (:GET, :CREATE, :DELETE, etc.). It's how the parser distinguishes OmniQL syntax from native SQL or other query languages. WHERE, AND, OR, LIMIT etc. are clauses. They modify the command but aren't commands themselves. So the rule is simple: commands get :, clauses don't. Think of it like a terminal. You prefix the command (git push) but not the flags (--force). Same idea here.

Why does JOIN get the prefix then? Is it a command? I would assume that it is a GET clause.

In OmniQL, JOIN isn't a clause inside another query. It's a standalone operation. You write :INNER JOIN Order User ON user_id = id, not :GET ... JOIN .... Since it starts the query and tells the engine what to do, it gets the : prefix. The rule is: anything that begins a query gets :, anything that modifies it (WHERE, ON, LIMIT) doesn't. This is actually a deliberate design choice. In SQL, JOIN lives inside a SELECT so you end up with one big statement doing multiple things. In OmniQL each : command does one thing. Flat and predictable rather than nesting clauses inside clauses. This also lets the engine translate consistently whether it outputs SQL JOINs for Postgres and MySQL or a $lookup aggregation pipeline for MongoDB. Same syntax, engine handles the rest.

I like arrow for its type system. It's efficient, complete and does not have "infinite precision decimals". Considering Postgres's decimal encoding, using i256 as the backing type is so much saner approach.