SONUB
EN English 한국어 日本語 中文 हिन्दी বাংলা اردو Español Português Français Deutsch Русский العربية Bahasa Indonesia Tiếng Việt ไทย Türkçe

How to enable notifications

Notifications are unavailable in this browser or on this address. Try a supported browser on the secure SONUB site.

If notifications are blocked, allow them in your browser settings.

  1. Open the site controls beside the address bar, or your browser’s site settings. Set Notifications for this site to Allow.
  2. In your device settings, allow notifications for your browser and check Do Not Disturb or Focus.
  3. Return to SONUB, reload the page, and use the bell to enable notifications.

On iPhone or iPad, add SONUB to your Home Screen, open it there, then allow notifications.
OpenAI

Codex — OpenAI’s coding agent

Type codex in a project folder and it starts. It reads your project, edits files and runs commands to test its own work. This page covers installing it and your first run, and links to the course chapters that go deeper.

Advanced — extend it: config.toml, codex exec, MCP, skills, hooks

Fit Codex to your way of working with the config file and profiles, put it into scripts with codex exec, connect outside tools with , teach repeated jobs with skills and enforce must-follow rules with hooks.

config.toml and profiles — fit it to your way of working

Codex settings live in ~/.codex/config.toml. Options you used to add every time become defaults once written here. Settings that differ by job go into profile files.

  • model · model_reasoning_effort — the model to use and how hard it thinks
  • approval_policy · sandbox_mode — the approval policy and sandbox (the values from Intermediate)
  • A profile is a file ~/.codex/<name>.config.toml. Choose it with codex -p <name> and its values sit on top of the base settings (the old [profiles.x] tables are no longer read).
  • -c key=value changes a setting for this run only (for example -c sandbox_workspace_write.network_access=true).
~/.codex/config.toml
model_reasoning_effort = "high"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"
~/.codex/review.config.toml
# a profile: codex -p review
model_reasoning_effort = "xhigh"
sandbox_mode = "read-only"
Terminal
codex -p review
codex -c sandbox_workspace_write.network_access=true

A .codex/config.toml in a project holds settings for that project only — it is read only in projects you have marked as trusted.

codex exec — automate without the chat screen

codex exec "…" does the job once without the chat screen and exits. Progress goes to stderr and the final answer to stdout, so it fits well into scripts, cron and .

  • It is read-only by default. Add --sandbox workspace-write to let it edit files.
  • --json sends progress as JSON lines (JSONL), -o <file> saves the final answer to a file, and --output-schema <file> gets an answer that matches a JSON Schema.
  • Run it with no prompt and standard input becomes the prompt; pipe input in together with a prompt and the input is appended.
  • Outside a Git repository you need --skip-git-repo-check. codex exec resume --last continues the previous run.
Terminal
# Ask once, print the answer (read-only by default)
codex exec "Summarize what changed in the last 5 commits"

# Allow edits inside this folder
codex exec --sandbox workspace-write "Fix the failing test in tests/cart.test.ts"

# Pipe input in
cat error.log | codex exec "Find the cause"

# For scripts: JSON events, the final answer in a file, a JSON Schema answer
codex exec --json "List the TODOs in src/" > events.jsonl
codex exec -o notes.md "Write release notes for this week"
codex exec --output-schema schema.json "Rate the test coverage of each file"

# Continue the last run
codex exec resume --last "Now add tests for it"

In CI, pass CODEX_API_KEY only to the step that runs Codex, so scripts in other steps cannot see the key.

MCP — connect outside tools

MCP (Model Context Protocol) is an open standard that lets tools use outside services (issue trackers, , , document tools). Add an MCP to Codex and it can use that server's tools — the same servers Claude Code uses work as they are.

  • codex mcp add <name> -- <command> — add a server that runs on your computer (stdio).
  • codex mcp add <name> --url <url> — add a remote server (streamable HTTP).
  • Added servers are saved in [mcp_servers.<name>] tables in config.toml. During a conversation, /mcp shows their status.
Terminal
# A server that runs on your computer (stdio)
codex mcp add playwright -- npx @playwright/mcp@latest

# A remote server (streamable HTTP)
codex mcp add notion --url https://mcp.notion.com/mcp

codex mcp list
~/.codex/config.toml
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
tool_timeout_sec = 60

Add only MCP servers you trust. A server that fetches outside text can bring in instructions hidden in that text (prompt injection).

Agent skills — teach it jobs you repeat

A is a folder with a SKILL.md in it — the same open format as Claude Code. Normally Codex knows only each skill's name and description; when a job matches the description, it reads the body and follows it. The old custom (~/.codex/prompts) should now be turned into skills.

  • .agents/skills/<name>/SKILL.md is for this repository, ~/.agents/skills/ for all your projects.
  • Call one directly with $<skill name> or pick from the list with /skills. It also uses one on its own when the description fits.
  • Write name and description, and keep scripts and reference documents in scripts/ and references/.
  • Ask the built-in $skill-creator and it helps you make a new skill.
.agents/skills/release-notes/SKILL.md
---
name: release-notes
description: Write release notes from the git log. Use when the user asks for release notes or a changelog.
---

1. Find the last tag: `git describe --tags --abbrev=0`
2. Read the commits since then: `git log <tag>..HEAD --oneline`
3. Group them under Added / Fixed / Changed, in plain sentences.

Hooks — commands that always run at set moments

A hook is a command Codex always runs at a set moment. A request in AGENTS.md can be forgotten, but a hook runs every time. Use hooks to run a formatter, block dangerous commands and get a notification when work is done.

  • Put them in ~/.codex/hooks.json (you) or .codex/hooks.json in the repository (project).
  • Attach them to moments such as PreToolUse and PostToolUse (before and after a tool), UserPromptSubmit (when you send a request), Stop (when it finishes its answer) and SessionStart (when a session starts).
  • matcher chooses the tools, and if the command ends with exit code 2 the action is blocked.
  • If you only need notifications, put a program in notify in config.toml — it runs with a JSON argument each time a turn ends.

A new hook runs only after you mark it as trusted in /hooks. Trust a hook from someone else only after you have read and understood its command.

Advanced practice

  1. Write your default approval and sandbox in ~/.codex/config.toml, make a read-only review profile (review.config.toml) and use it with codex -p review.
  2. Write a script that summarizes this week's commits into a file with codex exec -o.
  3. Add one MCP server and check it with /mcp.
  4. Turn one job you do often into a skill in .agents/skills/ and call it with $name.
  5. Use a PostToolUse hook so a formatter runs on every file edit, and mark it as trusted in /hooks.

Done all five? Move on to the [Master] tab.

Official documentation

Checked against the official documentation on 2026-10-18. These tools change often — if a command fails, see the official docs.

Guidelines

AI

Certificate

Study

Vibe Coding

Game

Practice

Teachers

Chat

Forum

Create

Community

More

Glossary

Pick a word you don't know. You'll see a simple explanation and related terms.

No matching term yet.

Pick a term to see its explanation.