Automation on KnightLi Blog

Reading the Official Codex Article: How to Get the Most Out of Codex

Wed, 27 May 2026 08:21:18 +0800

Most developers start using Codex with code tasks: reading a repository, editing a diff, running tests, and opening a pull request.

That is still Codex’s core use case. But a lot of work on a computer is already surrounded by code and tools: running shell commands, browsing web pages, calling APIs, exporting documents, responding to messages, and triggering automation. As these capabilities gradually connect to Codex, it becomes less a narrow coding assistant and more a system that helps you complete work on a computer.

The Codex app makes this shift more concrete. A thread can preserve context, call tools, display artifacts, and keep moving across multiple rounds of prompts instead of restarting every conversation from scratch.

To use Codex more fully, the key is combining these capabilities:

Durable threads for preserving long-term context
Voice input, steering, and queuing, so the user still controls the process
browser, computer use, MCP servers, and connectors, so Codex can move beyond the repository
thread automations and Goals, so tasks can keep progressing after the user leaves
The sidebar for reviewing code, documents, slides, web pages, and other artifacts
Shared memory, which writes important context outside the thread

Durable threads

Durable threads are long-running threads that can preserve work context across multiple sessions.

Pinned threads are a very practical entry point. They are a good place for workflows you return to repeatedly, such as:

A Chief of Staff thread
A release thread
A document review thread
An external monitoring thread

These are not temporary chats, but persistent workspaces. Codex can return to the same thread later and reuse prior decisions, preferences, and background information, avoiding the need to rebuild context from zero every time.

Keyboard shortcuts also make this smoother. Command-1 through Command-9 can jump directly to saved threads.

Voice input

The value of voice input is that it captures ideas before they have been organized into formal text.

Codex has built-in voice input. It is especially useful for fuzzy starting points that feel natural to say but awkward to type:

1
2
3

我记得 Slack 里好像有个叫 Ben 的人提过这个。
具体细节我不记得了。
帮我去找一下。

For an agent that can search, organize context, and report back, this is often enough to get started.

Voice is also useful for two- or three-minute thought dumps. Meeting transcripts, dictated planning notes, and unorganized raw records are often more useful than a one-sentence summary, because they preserve uncertainty, emphasis, and unfinished lines of thought.

Steering and queuing

Voice becomes more useful when combined with explicit control.

Steering means inserting a new direction while a Codex task is running, so it can change course before the current step finishes.

For example, while reviewing a web page, the user can annotate in the sidebar and interrupt the current task at the same time:

1
2
3

这里再小一点。
这两个元素之间的间距不对。
这句文案写错了。

Queuing is different. It does not interrupt the current task; it places the next piece of work in the queue:

`1`	`这项工作完成后，把预览链接发给 Slack 里的 reviewer。`

Steering changes what Codex is doing right now. Queuing changes what it should do next. Both keep the user close to the work as the task unfolds.

Tools and reachable scope

Once threads have continuity, the next question is: what can they operate?

Codex can expand outward layer by layer:

$browser: good for web page inspection, annotation, and review in the sidebar
@chrome: good for browser workflows that depend on the user’s Chrome login state
@computer: good for tasks that can only be completed through a desktop GUI

MCP servers and connectors extend the same idea into more workflows. Slack, Gmail, and Calendar matter because many tasks do not first appear as code. They appear as messages, emails, and calendar problems.

Skills are good for solidifying repeated work. Once a process has proven useful, it can be packaged as a skill so Codex does not need to relearn the same steps next time.

Continue working from anywhere

The Codex mobile app changes how long the user has to stay in front of a computer.

A task can start on a Mac because the files, permissions, and local environment are there. Later, the user can leave the desktop and continue confirming, adding details, or changing direction from a phone.

This is valuable in many small scenarios: while Codex runs a long task, the user can leave their desk; if it needs confirmation, they can respond while away; if the direction is wrong, they can redirect it in time. What truly stays in place is the local environment, not the user.

Automation

Automations can run Codex work on a schedule.

If a recurring task should restart from a specific workspace, such as a daily report or routine repository check, scheduled automation is a good fit. If the schedule should return to an existing conversation and reuse its context, thread automation is better.

Thread automations are more like heartbeat wake-ups: they return to the same Codex thread on a fixed rhythm.

Pinned threads require the user to come back actively, while thread automation can check every few minutes or every few hours, keep running until a condition is satisfied, and adjust its rhythm over time.

For example, a Chief of Staff thread could run every 30 minutes:

1
2
3

每 30 分钟检查 Slack 和 Gmail，找出需要我注意但还没有回复的消息。
帮我判断哪些最重要。
如果有人问我问题，尽可能深入研究答案，并替我起草回复，但不要发送。

When the user returns, the most time-consuming context gathering is often already done. The actual decision about whether to send still belongs to a human.

Thread automations are also useful for feedback loops. They can periodically check pull request comments, Google Docs comments, or Slack replies, continuing adjacent work while the user is away.

For example, in an animation workflow, a reviewer sends video feedback in Slack, and a thread automation checks the thread on a schedule. If there is a new comment, it re-renders the version and replies to the reviewer in the same Slack thread. If an integration cannot complete the final upload, desktop automation can still fill in the last step through the GUI.

This loop may cross Slack, the codebase, and desktop applications, but to the user it still stays inside one workflow.

Goals

Goals are best suited to tasks that have a clear endpoint and can be pushed forward continuously by an agent.

A weaker goal might be:

`1`	`实现这个 Markdown 文件里的计划。`

A stronger goal has measurable completion criteria.

For example, when migrating an internal tool from Python to Rust, you can first create the new directory and then define the target clearly: the new implementation is only complete once the unit tests pass.

A Goal is essentially continuous execution plus a verifier. The user needs to define the outcome, the stopping condition, and the signals that indicate whether Codex is getting closer to the goal.

Common verifiers include:

Test suites
benchmark
bug reproduction
validation matrix
End-to-end workflows that must keep passing

A task can be ambitious, but without verification criteria, it is more like a wish than a goal.

The sidebar places work artifacts next to the conversation that generated them. The user does not need to export files, switch context, and then describe the problem afterward. The artifact might be code, but it could also be a deck, PDF, web page, spreadsheet, or another artifact generated during the work.

It is especially useful for four types of work:

Inspecting an artifact
Annotating places that need changes
Operating a web interface
Reviewing changes

Markdown, spreadsheets, data tables, documents, and slides can all be viewed directly in the sidebar. The user can inspect, annotate, and revise them without turning the process into another handoff.

If it is a deck or PDF, it can stay beside the thread that produced it and accept review and fixes at any time.

The browser is a similar work surface. Codex can open a rendered page, inspect it, respond to user annotations on the page, and continue fixing the same object. A web page is both the output and the control surface.

These surfaces are especially good fits for the sidebar:

Lightweight static artifacts such as index.html
Storybook
Remotion Studio
Browser slides
Data analysis applications

A standalone index.html file can become a long-lived interactive artifact without necessarily requiring a server. Thread automations can also refresh static artifacts on a schedule, so the user sees new results when they return.

Shared memory

Long threads are useful, but important context should not exist only in the conversation history.

Shared memory means storing durable context outside the thread, so future work can continue from an explicit, reviewable place.

One stable practice is to anchor durable threads in an Obsidian vault. In practice, this can be very simple: a set of ordinary files that are easy to inspect, edit, move, and preserve long term. Teams can put it in cloud storage, Git, Dropbox, Google Drive, or another sync layer.

A vault might look like this:

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

A top-level AGENTS.md can explain how Codex should maintain this workspace: what information should be written down, where it should go, and when not to create noise.

A practical AGENTS.md might look like this:

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

Do not copy a particular vault structure blindly. What matters more is teaching the agent where long-term context should live, which information is worth preserving, and when it should avoid repeatedly changing files.

The repository stores code. The vault stores rolling context: relevant people, what happened, where things are blocked, who owns what, what comes next, and the details that would otherwise disappear between conversations if they were not written down.

Codex also has first-party memory capabilities, configurable in Settings > Personalization > Memories. They are good for recording preferences, repeated workflows, and common pain points, but they work better as a supplement to explicit written context than as a replacement. Chronicle is moving in the same direction as well: helping Codex build memory from recent screen context.

Expanding outward from code

Codex still starts with code. But more of the work around code can now be reached by the same system: MCP servers, browser interfaces, desktop control, thread automations, and reviewable artifacts.

This changes how Codex is controlled. Steering interrupts work in progress. Queuing schedules the next step. Thread automations keep a thread active after the user leaves. Goals add clear endpoints and verification signals to long-running tasks.

When these capabilities connect, Codex can move a workflow from instruction to execution and then onward to artifact review. Even after a task has left the code repository, it can still be completed inside the same system.

Original link: Getting the most out of Codex

ai-goofish-monitor: An Open-Source AI Monitoring System for Goofish Listings

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor is an open-source Goofish product monitoring system from Usagi-org.

Its goal is clear: automate Goofish search, filtering, product analysis, result logging, and notifications, so users can find matching second-hand listings faster. The project uses Playwright for browser automation and connects to image-capable AI models to judge product information more intelligently.

Project link: https://github.com/Usagi-org/ai-goofish-monitor

The Short Version

ai-goofish-monitor is closer to a “Goofish purchasing intelligence dashboard” than a simple keyword alert script.

It has several notable traits:

A complete web admin UI for managing tasks, accounts, AI criteria, logs, and results.
Concurrent multi-task monitoring, where each task can define keywords, price range, filters, and AI Prompt.
Playwright-based page automation, useful for scenarios that require login state and page interaction.
AI-based product judgment, not just keyword matching.
Notifications through ntfy.sh, WeCom, Bark, Telegram, Webhook, and other channels.
Cron scheduling, multi-account management, proxy rotation, retry handling, and Docker deployment.

It fits users who often search Goofish for specific items, such as second-hand electronics, cameras, GPUs, hard drives, game consoles, musical instruments, appliances, and collectibles. But it is not an “automatic bargain hunter.” Goofish search results change, login states may expire, and platform risk controls can affect automation stability. Treat it as an assisted filtering tool, not a replacement for human judgment.

What Problem It Solves

Finding second-hand products on Goofish often has several pain points:

There are too many listings to browse manually.
Titles and descriptions are inconsistent, so keywords can miss or misclassify listings.
Good prices appear briefly and may be gone by the time you see them.
The same product may differ by region, price, condition, and seller.
Low-priced listings can include accessories, damaged goods, refurbished items, or misleading titles.
Watching multiple keywords continuously is hard to sustain manually.

Basic keyword alerts solve only part of this. Searching for “ThinkPad X1” may mix in accessories, broken screens, empty boxes, or disassembled parts. Searching for “Sony A7C” may return lens bundles, rentals, clickbait titles, or abnormal prices.

ai-goofish-monitor’s idea is to use automation to collect candidate listings, then let AI apply your criteria, and finally push the results worth attention.

Core Features

The project README lists a fairly complete feature set:

Visual web management: task management, account management, AI criteria editing, run logs, and result browsing.
AI-driven workflow: create tasks with natural language and analyze products with multimodal models.
Concurrent tasks: each task can define keywords, prices, filters, and AI Prompt independently.
Advanced filters: free shipping, newly listed time range, and province / city / district filtering.
Instant notifications: ntfy.sh, WeCom, Bark, Telegram, Webhook, and more.
Scheduled execution: Cron-based periodic tasks.
Account and proxy rotation: multi-account management, task-account binding, proxy pool rotation, and retry handling.
Docker deployment: containerized deployment support.

Together, these cover the full chain from creating a monitoring task to receiving a matching alert.

Workflow

A typical workflow looks like this:

Deploy the service and open the Web UI.
Import Goofish account login state.
Create a monitoring task.
Set keywords, price range, region, newly listed window, and other filters.
Write criteria or let AI generate them.
Run the task in real-time or on a schedule.
Playwright opens pages and extracts product information.
AI checks title, description, images, and Prompt against your needs.
Matching results are written to SQLite.
The system sends notifications through configured channels.
You review results, logs, and price history in the Web UI.

AI matters most at step 8. It can understand natural language criteria like “good condition, reasonable price, no accessories, no repaired units, preferably local pickup,” which is more flexible than simple keyword rules.

Docker Deployment

The project recommends Docker deployment:

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

The default Web UI address is:

`1`	`http://127.0.0.1:8000`

The official image is:

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

If the image pulls slowly, the README also gives an accelerated mirror example:

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

The Docker image includes Chromium, so the host does not need an extra browser. Default persistent directories include:

data/: main SQLite storage for tasks, results, and price history.
state/: login-state cookie files.
prompts/: task prompts.
logs/: runtime logs.
images/: product images and temporary task image folders.

If you change SERVER_PORT in .env, also update the port mapping in docker-compose.yaml.

Minimum Configuration

The minimum configuration mainly covers the AI model and Web UI login:

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

The first three are required for AI model access:

OPENAI_API_KEY: model API key.
OPENAI_BASE_URL: OpenAI-compatible endpoint.
OPENAI_MODEL_NAME: model name that supports image input.

WEB_USERNAME and WEB_PASSWORD are used for Web UI login. The README mentions the default credentials admin/admin123; change them in production.

First Use

The first-use flow is roughly:

Open http://127.0.0.1:8000.
Log in to the Web UI.
Go to Goofish account management.
Use the provided Chrome extension to export Goofish login-state JSON.
Paste the login state into the system.
The state file is saved to state/, for example state/acc_1.json.
Return to task management, create a task, and bind an account.
Run the task and check results.

The key part is login state. Goofish does not provide a standard open API for arbitrary third-party scraping, so the project uses browser login state to simulate normal page access. Expired login state, risk controls, captchas, and account anomalies can all affect task execution.

AI Tasks and Keyword Tasks

The project supports two task creation modes.

The first is AI判断.

You can enter detailed requirements, and the system asynchronously generates analysis criteria. This fits complex needs, for example:

Only the main unit, no accessories.
Alert only when the price is clearly below market.
Good condition, with no water damage, repair, or hidden defects in the description.
Prefer local listings and face-to-face pickup.
Images should show serial number, packaging, or key accessories.

The second is 关键词判断.

This is closer to traditional rule-based monitoring: create tasks directly from keywords, prices, regions, and other conditions without AI generation. It fits simple rules where some false positives are acceptable.

In practice, you can mix both: keywords handle initial filtering, AI reduces false positives.

What the Web UI Does

The Web UI is a major difference between this project and ordinary scripts.

The task management page can configure:

AI-created tasks.
Keyword rules.
Price ranges.
Newly listed windows.
Region filters.
Account binding.
Scheduling rules.

The account management page can:

Import Goofish account login state.
Update login state.
Delete accounts.
Assign accounts to tasks.
Let the system choose accounts automatically.

Results and logs pages can:

View matching products.
Export results.
Search history.
Inspect task execution.
Troubleshoot login expiration, risk controls, and AI call issues.

The system settings page can:

View system status.
Edit Prompt.
Adjust proxy and rotation configuration.

For long-term monitoring, the Web UI is important. Without it, many tasks quickly make configuration, logs, results, and notifications hard to maintain.

Data Storage

The current online primary storage is SQLite, with the default path:

`1`	`data/app.sqlite3`

Docker mounts the SQLite main database by default:

`1`	`./data:/app/data`

On startup, the app creates tables automatically and tries to import historical data once from old config.json, jsonl/, and price_history/.

Note that state/, prompts/, logs/, and images/ remain filesystem directories and are not stored in SQLite. Product images are temporarily saved to directories like:

`1`	`images/task_images_<task_name>/`

They are cleaned up by default after the task ends.

This structure fits personal or small-team deployments: SQLite is lightweight and easy to migrate, while files keep login state, images, and logs easy to inspect.

Notification Channels

The project supports multiple notification channels. Common configuration items include:

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

Notifications are central to the experience. If a monitor only writes results to a backend, users still need to keep checking the page. With push notifications, matching listings reach the user immediately.

A practical setup is to tier notifications by item value:

Normal keyword hits are written only to the backend.
High-confidence AI results are pushed to the phone.
High-value items are pushed to WeCom or Telegram.
Enable more logs during debugging, then reduce noise after stabilization.

Developer Run

Without Docker, local development requires:

Python 3.10+
Node.js + npm
Playwright CLI
Chromium or Chrome / Edge browser

Basic commands:

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

One-command startup:

1
2

chmod +x start.sh
./start.sh

start.sh checks Playwright CLI and browser conditions, installs dependencies, builds the frontend, copies build artifacts, and starts the backend.

Start the backend manually:

`1`	`python -m src.app`

Or:

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

Frontend development:

1
2
3

cd web-ui
npm install
npm run dev

Testing and build:

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

Who It Fits

ai-goofish-monitor fits users who:

Frequently watch Goofish for specific models.
Want to monitor second-hand electronics, cameras, game devices, hardware parts, and similar goods.
Want to automate “keyword search + manual screening.”
Have an OpenAI-compatible model API and accept AI judgment costs.
Are comfortable with Docker or basic command-line deployment.
Need matching results pushed to phone, WeCom, or Telegram.

It is less suitable if you:

Know nothing about deployment and only want a ready-to-use app.
Do not want to handle login state, captchas, or account risk controls.
Need official authorization and strongly compliant data APIs.
Want large-scale high-frequency platform scraping.
Expect AI to automatically judge trading risk and place orders for you.

Risks and Boundaries

Tools like this need clear boundaries.

First, follow platform rules.

Goofish has its own terms, risk controls, and account security mechanisms. Automation may trigger restrictions. Do not scrape at high frequency, bypass risk controls, harass sellers, bulk-collect private information, or disrupt platform order.

Second, protect account login state.

Files in state/ are login-state cookie files. They are effectively account access credentials. Do not commit them to Git, and do not put them on untrusted servers. If the server is exposed to the public internet, change the default Web UI password and place it behind a VPN, reverse-proxy authentication, or an internal network.

Third, AI judgment is not a factual guarantee.

AI can reduce false positives, but it cannot guarantee product authenticity, seller trustworthiness, reasonable pricing, or transaction safety. You still need to review product details, seller reputation, chat history, shipping method, and payment process.

Fourth, watch cost.

If every candidate listing is analyzed by a multimodal model, costs can rise quickly. Use keyword, price, and region filters first, then send a smaller candidate set to AI.

Fifth, protect privacy.

Product screenshots, chat-related content, account state, and notification content may all contain sensitive information. Protect notification Webhooks, log directories, and databases carefully.

Difference from Ordinary Scripts

Ordinary Goofish monitoring scripts usually do three things:

Search keywords.
Check prices.
Send notifications.

ai-goofish-monitor goes further:

Manage tasks and accounts through Web UI.
Express complex buying criteria with AI Prompt.
Use multimodal models to inspect product images and descriptions.
Store results and price history in SQLite.
Use log pages to diagnose task failures.
Improve stability through proxy rotation and multi-account mechanisms.
Support long-running schedules with Cron.

Because it does more, it also costs more to deploy and maintain. For normal users, Docker is the easiest path. For developers, the Web UI, FastAPI, Playwright, and SQLite structure is also friendly for secondary development.

How to Use It

A practical approach is to start with small tasks.

For example, if you want a second-hand camera, create a task like this:

Keywords: A7C, 索尼 A7C
Price range: set an upper limit based on market price
Region: prefer same province or local city
Newly listed window: last day or last few hours
AI criteria: exclude lens-only listings, repaired units, obvious accessories; pay attention to shutter count and condition
Notification: push only results that pass AI judgment

After it runs stably, gradually add more tasks. Do not start with dozens of keywords, multiple accounts, and high-frequency Cron. First check login stability, false-positive rate, AI cost, and notification noise, then tune parameters.

Summary

ai-goofish-monitor moves Goofish monitoring from a “keyword script” to a manageable AI monitoring system. It uses Playwright for page automation, AI for complex judgment, Web UI for tasks and results, SQLite for storage, and multiple notification channels for delivery.

It is best for individuals or small teams monitoring specific products, especially second-hand electronics, hardware, and cameras where prices fluctuate, timing matters, and descriptions are noisy.

But it must be used carefully: protect login state, change default passwords, keep scraping frequency restrained, review AI results manually, and respect platform rules and privacy boundaries. As an assisted filtering tool, it can be valuable. As a fully automated trading system, it is easy to overestimate.

References:

goose: An Open Source AI Agent with Desktop, CLI, and API

Fri, 08 May 2026 13:41:15 +0800

goose is an open source AI agent that runs on your own machine. It is not limited to code completion; it aims to cover code, research, writing, automation, data analysis, and other tasks. The README positions it as a desktop app, CLI, and API that can serve both normal users and custom workflows.

The project has moved from block/goose to the Agentic AI Foundation (AAIF) at the Linux Foundation. The current repository is:

`1`	`https://github.com/aaif-goose/goose`

goose is mainly written in Rust and TypeScript and uses the Apache-2.0 license. Its GitHub description says it is an open source, extensible AI agent that goes beyond code suggestions and can install, execute, edit, and test with any LLM.

What Problem It Solves

Many AI coding tools focus on suggestions or local code edits. goose takes a broader view: let an AI agent complete tasks directly on your machine.

It can be used for:

Code changes and tests.
Local automation.
Research and writing.
Data analysis.
Multi-step workflows.
Embedding through an API.
Tool extension through MCP.

If you only need IDE completion, a Copilot-style tool may be enough. goose is more useful when you want AI inside the local task execution chain.

Desktop, CLI, and API

goose has three entry points.

The desktop app supports macOS, Linux, and Windows. It is good for users who prefer a visual interface.

The CLI fits terminal workflows and local development automation.

The API lets other systems or internal tools embed goose as an agent runtime.

Personal users can start with the desktop app or CLI. Teams and workflow builders should also look at the API and custom distribution support.

Installation

The README recommends downloading the desktop app:

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI install:

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases provide builds for multiple platforms. The latest release checked here was v1.33.1, published on 2026-04-29, with macOS, Linux, Windows, deb, rpm, and Flatpak assets.

After installation, configure a provider from the official quickstart and test in a low-risk directory first. goose can execute local tasks, so avoid giving it broad permissions in a production repository from the start.

Providers

goose supports 15+ providers, including:

Anthropic
OpenAI
Google
Ollama
OpenRouter
Azure
Bedrock
other cloud or OpenAI-compatible providers

It can use API keys, and it can also use existing Claude, ChatGPT, or Gemini subscriptions through ACP.

ACP is important because many users already pay for subscriptions, but different tools cannot easily reuse them. goose uses ACP providers to bring those subscriptions into an agent workflow.

Provider policies change quickly. Check whether the access method is allowed, whether there are quotas, and whether it is suitable for company code or sensitive data.

MCP Extensions

goose supports Model Context Protocol extensions. The README mentions 70+ extensions.

MCP matters because an agent should not only chat and edit files. Through standard protocol servers, it can connect to documentation, databases, browsers, internal systems, search services, design tools, or project management tools.

For teams, MCP can become a safer integration layer: expose internal capabilities through explicit interfaces instead of letting the model touch every system directly.

Difference from a Coding Assistant

goose is not just a code completion tool. It is closer to a local agent runtime.

Common coding assistants focus on:

Code completion.
Code explanation.
Function generation.
Local editor edits.

goose emphasizes:

Local task execution.
Multi-step workflows.
Switchable providers.
Extensions.
Desktop and CLI.
Embeddable API.
Non-code tasks too.

This also means more complexity. You must think about model configuration, permissions, extensions, workspace scope, logs, and credentials.

Custom Distributions

The repository includes CUSTOM_DISTROS.md, which explains how to build a custom goose distribution with preconfigured providers, extensions, and branding.

This is useful for teams:

Preconfigure allowed model providers.
Connect internal MCP servers.
Set safety policies and logging.
Block disallowed external services.
Apply company branding and onboarding.

Members do not need to configure everything from scratch, and the risk of wrong provider or key setup is reduced.

Suggested Use

Start gradually:

Install the desktop app or CLI.
Configure one known-good provider.
Run simple tasks in a test directory.
Observe what it reads and executes.
Add MCP extensions.
Try larger repositories later.

Keep a few habits:

Commit important changes before agent work.
Do not store API keys in project files.
Use high-permission modes only in trusted workspaces.
Review company data and provider policy first.
Keep human review for automation results.

Who Should Use It

goose is a good fit if you want a desktop and CLI AI agent, multiple model providers, MCP integration, API embedding, or custom team distributions. It may be heavy if all you need is IDE code completion.

Summary

goose is an open source AI agent under AAIF/Linux Foundation. It provides desktop, CLI, and API entry points, supports 15+ providers, ACP subscription access, and 70+ MCP extensions.

Its value is not only writing code, but placing models, tools, extensions, and local execution into one agent framework. Start small, define permission and data boundaries, then expand usage.

References

Claude Code Hooks Mastery: An Introduction to 13 Hook Lifecycle Events and Automation Control

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery is a learning project focused on Claude Code Hooks.

It is not just a collection of scattered scripts. It explains the Claude Code hook lifecycle, configuration methods, script patterns, and common automation scenarios in one place. For people who want Claude Code to be more controllable and more like an engineering assistant, this kind of material is worth reading.

Claude Code can already read code, edit files, and run commands by default. But if you want it to automatically check permissions, block risky operations, inject project rules, run tests, or remind it of team conventions at specific moments, chat instructions alone are not stable enough. The value of hooks is that they turn “rules I need to remind the AI about every time” into executable workflow.

What Problems Hooks Solve

After using Claude Code for a while, common pain points include:

Every new session needs the same project rules repeated
You worry that it may run commands it should not run
You want checks before and after file edits
You want formatting, tests, or security scans before committing
You want team conventions as fixed workflow instead of verbal reminders
You want context before and after tool calls for logging or blocking
You want complex tasks to trigger subagents or dedicated scripts

Hooks are designed for these “automatic actions at fixed moments.”

You can think of them as event hooks in the Claude Code workflow. When a session starts, a user submits a prompt, the model is about to call a tool, a tool call finishes, or an agent is about to stop, Claude Code can run the scripts you configured.

The 13 Hook Lifecycle Events

One of the main points in the project README is that it systematically covers the 13 Claude Code hook events.

These events span multiple stages, from session startup to tool calls, and from user input to agent termination. By purpose, they can be roughly grouped as:

Session startup: initialize environment and inject project context
User input: inspect prompts, add rules, and perform auditing
Before tool calls: permission checks, command blocking, and security validation
After tool calls: log results, trigger formatting, and run verification
Task ending: summarize, clean up, notify, or save state

This lifecycle design means you do not need to put every rule into one very long prompt.

For example, permission control should happen before tool calls. Formatting checks are better after file edits. Project rule injection is better at session startup or after user input. Putting rules at the right hook point is usually more reliable than stuffing everything into a system prompt.

Where Configuration Lives

Claude Code hooks are usually configured through settings files.

Common locations include:

User-level configuration: ~/.claude/settings.json
Project-level configuration: .claude/settings.json

User-level configuration is good for personal preferences, such as general security rules, command blocking, and log paths.

Project-level configuration is better for repository-specific rules, such as which tests must run, which directories cannot be edited, how generated files are handled, and which checks are required before commit.

If you use Claude Code in a team, it is better to put project-level configuration into the repository. That way everyone opens the project with the same AI collaboration constraints instead of relying on personal memory.

Why Single-File Scripts Matter

The project emphasizes UV single-file scripts.

The benefit is simple deployment. A single Python file can declare dependencies and run without maintaining a complex environment for one hook. This fits hooks well because many hooks only do one small thing:

Check whether a command is allowed
Determine whether a file path is safe
Read project rules and return them to Claude
Scan output for sensitive information
Run formatting or tests after edits
Write events to logs

The smaller a hook script is, the easier it is to maintain, and the less likely it is to become a new complicated system.

What Automation Can Hooks Do

claude-code-hooks-mastery shows many directions. In real work, the most common ones are below.

1. Permission and Security Control

This is the most direct use of hooks.

Before Claude Code executes a command, a hook can inspect the command content. If it contains high-risk actions such as deletion, reset, cleanup, or overwrite, it can block execution or require manual confirmation.

Similar rules can apply to file paths:

Do not modify production configuration
Do not write to secret files
Do not delete migration scripts
Do not touch specific directories
Do not run unapproved network commands

Putting this protection before tool calls is more reliable than writing “do not perform dangerous operations” in a prompt.

2. Context Injection

Many projects have fixed background information:

Tech stack
Coding conventions
Test commands
Branching strategy
Directory structure
Prohibited actions
Rules for generated files

Telling Claude Code this manually every time is annoying and easy to forget. Hooks can automatically inject necessary context at session startup or after the user submits a prompt.

This is like giving Claude Code a project-level work manual. It does not replace the README or development documentation, but it helps AI enter the correct state before executing a task.

3. Verification After Edits

After Claude Code modifies files, hooks can automatically trigger checks.

Common actions include:

Run formatting
Run lint
Run unit tests
Check type errors
Scan generated files
Validate Markdown or JSON format

This helps reduce low-level mistakes. When AI edits multiple files, a lightweight verification pass after modification can reveal problems earlier.

However, hooks should not run heavy tasks by default. Running the full test suite after every file change can make the experience slow. A better approach is to choose checks based on file type, directory, and task risk.

4. Team Rule Validation

If a team already has clear conventions, some of them can be placed in hooks.

For example:

Commit message format
Code style rules
Do not directly edit certain generated files
Documentation must be updated together
API changes must update tests
Certain directories can only be generated by specific tools

This makes Claude Code more like part of the team workflow rather than an unconstrained external assistant.

Of course, hooks should not replace CI. They are better for local reminders and early blocking. Final validation should still belong to CI, review, and test systems.

5. Subagents and Dedicated Tasks

The README also mentions subagent-related content.

This type of usage is suitable for sending complex tasks into more specialized workflows. For example, the main conversation can understand the requirement, while a hook or configuration triggers dedicated checking, auditing, summarizing, or documentation tasks.

For individual users, the first useful step is not complex agent orchestration. It is better to hand repetitive, clear, low-risk actions to hooks first. More complex automation can come after the rules become stable.

Statusline and Output Styles

The project also covers statusline and output styles.

This may look like a small experience detail, but it matters for long-term Claude Code usage. A statusline can show current context, task state, environment information, or hints. Output styles can make Claude Code answers fit your working habits better.

If you collaborate with AI in the same terminal every day, these details affect efficiency. Good status hints reduce mistakes and help you quickly determine whether the current session is in the right project, branch, and environment.

Do Not Make Hooks Too Heavy

Hooks are powerful, but they are not the place to put everything.

Good rules are:

High-frequency actions should be fast
Security blocking should be clear
Output should be short
Failure reasons should be readable
Scripts should have a single responsibility
Heavy checks should be explicit commands or CI tasks

If a hook takes more than ten seconds every time, users will soon want to disable it. If a hook has vague blocking rules, both Claude Code and the user will struggle to understand what to do next.

Hooks are best for tasks with clear boundaries: allow or reject, add context, log events, run lightweight checks, and suggest the next step.

Who Should Use It

If you only occasionally ask Claude Code to edit a small piece of code, you may not need to study hooks deeply yet.

But this project is useful if you:

Use Claude Code frequently
Often let AI modify real project code
Worry about AI running dangerous commands
Want to automatically inject team rules into AI workflows
Want checks to run automatically after edits
Want to turn repeated reminders into configuration
Are building a more stable AI coding workflow

Hooks are especially meaningful in collaborative projects. They can turn part of team experience into scripts instead of relying on every person to remind AI manually.

Notes for Use

First, start with security hooks.

Compared with complex automation, command blocking, path protection, and sensitive file checks are easier to implement and immediately reduce risk.

Second, commit project-level rules carefully.

.claude/settings.json affects everyone who uses the repository. Before committing rules, make sure they do not over-restrict normal development or depend on paths that only exist on your machine.

Third, keep hook output concise.

Claude Code consumes this output. If it is too long, it pollutes the context. If it is too vague, it does not guide the next step. It is best to return only the necessary judgment and next recommendation.

Fourth, keep hooks debuggable.

When hooks increase in number, problems can come from configuration, scripts, permissions, paths, dependencies, or Claude Code itself. Clear logs make later debugging much easier.

Reference

disler/claude-code-hooks-mastery

Final Thought

The value of Claude Code Hooks is turning “rules I hope AI remembers every time” into workflows that actually execute.

If you already use Claude Code in real projects, hooks are a key step from “a coding assistant that can chat” toward “a constrained engineering collaborator.”

Automation on KnightLi Blog

Reading the Official Codex Article: How to Get the Most Out of Codex

Durable threads

Voice input

Steering and queuing

Tools and reachable scope

Continue working from anywhere

Automation

Goals

Sidebar

Shared memory

Expanding outward from code

ai-goofish-monitor: An Open-Source AI Monitoring System for Goofish Listings

The Short Version

What Problem It Solves

Core Features

Workflow

Docker Deployment

Minimum Configuration

First Use

AI Tasks and Keyword Tasks

What the Web UI Does

Data Storage

Notification Channels

Developer Run

Who It Fits

Risks and Boundaries

Difference from Ordinary Scripts

How to Use It

Summary

goose: An Open Source AI Agent with Desktop, CLI, and API

What Problem It Solves

Desktop, CLI, and API

Installation

Providers

MCP Extensions

Difference from a Coding Assistant

Custom Distributions

Suggested Use

Who Should Use It

Summary

References

Claude Code Hooks Mastery: An Introduction to 13 Hook Lifecycle Events and Automation Control

What Problems Hooks Solve

The 13 Hook Lifecycle Events

Where Configuration Lives

Why Single-File Scripts Matter

What Automation Can Hooks Do

1. Permission and Security Control

2. Context Injection

3. Verification After Edits

4. Team Rule Validation

5. Subagents and Dedicated Tasks

Statusline and Output Styles

Do Not Make Hooks Too Heavy

Who Should Use It

Notes for Use

Reference

Final Thought