goalctl, the first of the three, allows you to manage any Codex thread goal state externally.
Simply put, your agents, whether Codex, Claude, or just scripts, can now set goals for any other Codex agent with only its thread id.
A common situation where this may be required is plain subagent orchestration. Imagine you want to get 5 agents to work on different tasks with goals set. By default, you have two options: a) create 5 different Codex sessions or b) one orchestrator that will spawn 5 subagents. Either way, you will set the goals manually yourself, even if the orchestrator provides the texts, because Codex CLI doesn't provide tooling to manage goals for subagents.
With goalctl, on the other hand, the orchestrator scenario becomes much more attractive: after generating the goal texts and discussing the budget strategy, it can itself call goalctl CLI and activate the subagents to work, with zero manual intervention.
Low-level, it works like this:
1. Your agent uses the skill and/or bare CLI to set/replace/update the goal state of a target (itself or a subagent, for example)
2. goalctl under the hood starts a short-lived stdio app-server for the command
3. Then the tool makes requests to the server to change the state of the target's goal
4. It outputs the result and your agent gets the feedback
5. If the target should act now, the agent pings it with a normal message
I published ferrumctl: lightweight CLI tools for autonomous Codex workflows.
goalctl: goals/budgets
wakectl: wakeups/messages
readcov: files an agent actually inspected
I use them to orchestrate bug hunting.
What should I cover next: budgets, wakeups, or read coverage?