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 and reload the page. Once notifications are on, the bell disappears.

On iPhone or iPad, add SONUB to your Home Screen, open it there, then allow notifications.
Admin Log in Display theme Default theme Dark theme Pink theme Chat 1:1 Chat Group Chat Forum Notices News Suggestions Introductions Main menu Log out

Codex — OpenAI’s coding agent

Fit to your way of working with the and , put it into scripts with , connect outside tools with , teach repeated jobs with skills and enforce must-follow rules with .

Advanced — config.toml, codex exec, MCP, skills, hooks

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

)

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

  • · model_reasoning_effort — the model to use and how hard it thinks
  • · sandbox_mode — the 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). Do not confuse it with a profile: that is a Beta way to set file and permissions, and it cannot be mixed with sandbox_mode.
  • -c key=value changes a setting for this run only (for example -c sandbox_workspace_write.network_access=true).
  • When the same setting appears in several places, the strongest wins. From strongest: command-line flags and --config, the project .codex/config.toml (the nearest folder first, trusted projects only), the --profile file, ~/.codex/config.toml, cloud-managed defaults, /etc/codex/config.toml, then the built-in defaults.
  • web_search chooses how Codex searches: cached, indexed, live (the same as --search) or disabled.
  • shell_environment_policy sets which reach the Codex runs (inherit = "none" or "core" passes fewer). [features] turns optional features on and off. CODEX_HOME moves the settings folder away from ~/.codex, and that folder must already exist.
  • On , mxc is the recommended sandbox on compatible devices; elevated and unelevated are legacy fallbacks. For the standalone , set prefer_mxc = true under [features].
~/.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"

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 in projects you have marked as trusted.

codex exec — automate without the chat screen

)

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

  • It is read-only by default. Add --sandbox workspace-write to let it edit files.
  • --json sends progress as (JSONL), -o <file> saves the final answer to a file, and --output-schema <file> gets an answer that matches a .
  • Run it with no and standard input becomes the prompt; pipe input in together with a prompt and the input is appended.
  • Outside a you need --skip-git-repo-check. codex exec resume --last continues the previous run.
  • schema.json fixes the shape of the final answer. With --output-schema schema.json the answer comes back as with summary and files. If "additionalProperties": false is missing, the run stops with 1 and an "Invalid " error, so add it and run again.
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"
schema.json
{
  "type": "object",
  "properties": {
    "summary": { "type": "string" },
    "files": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["summary", "files"],
  "additionalProperties": false
}

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

)

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

  • codex mcp add <name> -- <command> — add a server that runs on your computer (stdio).
  • codex mcp add <name> --url <> — add a remote server ().
  • 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

Agent skills — teach it jobs you repeat

)

A is a folder with a 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 prompts (~/.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 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 is a command Codex runs at a set moment. A request in can be forgotten, but a hook runs whenever that moment comes. Use hooks to run a , block dangerous commands and get a notification when work is done. Treat them as a useful guardrail, not a complete enforcement boundary: hosted tools such as web search do not go through hooks, and some other tool can skip them.

  • Put them in ~/.codex/hooks.json (you) or .codex/hooks.json in the repository (project), or write inline [hooks] tables in config.toml. Use one form in each place.
  • Attach them to moments such as and (before and after a tool), (when you send a request), Stop (when it finishes its answer) and SessionStart (when a session starts).
  • chooses the tools. What exit code 2 does depends on the moment: on PreToolUse it stops the tool before it runs; on PostToolUse the tool has already run, so the reason in stderr only goes to Codex as feedback and the change stays.
  • If you only need notifications, put a in notify in config.toml — it runs with a JSON argument each time a turn ends.
  • Codex edits files with apply_patch (matched as Write or Edit) but can also write them with a command, so a formatter hook needs in matcher too. The hook receives its input as JSON on stdin.
.codex/hooks.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "sh .codex/hooks/format.sh",
            "statusMessage": "Formatting changed files"
          }
        ]
      }
    ]
  }
}
.codex/hooks/format.sh
#!/bin/sh
# Codex sends the hook input as JSON on stdin; this formatter does not need it.
cat > /dev/null
git status --porcelain --untracked-files=all | cut -c4- \
  | grep -E '\.(js|ts|css|html|json|md)$' | grep -v '^\.codex/' \
  | xargs -r npx --yes prettier --write >&2

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.

How the pieces fit together

)

Codex gives you several places to keep rules and repeated work. Each does a different job, so put each thing in the place made for it.

  • AGENTS.md — lasting instructions that shape how Codex works in this project.
  • Memories — useful from earlier work that Codex carries forward.
  • Skills — a repeatable process, packed so Codex can follow it when that job comes up.
  • Plugins — the installable form. Write a skill first, then package it as a plugin when you want to share it.
  • Hooks and MCP — hooks run your commands at set moments, and MCP connects Codex to systems outside the workspace.
  • — helpers that take delegated work, such as a review, so the main conversation stays focused.
  • Together, for example: AGENTS.md says to run test before finishing, a recalls which file you were fixing, a skill writes the , MCP reads the issue from your tracker, and a reviewer subagent checks the .

Keep required rules in AGENTS.md or checked-in documents. A memory is a helpful recall layer, not the only source for a rule that must be followed.

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 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. It should appear in /skills. If it does not, check the folder and the name in SKILL.md, then restart Codex.
  5. Copy the two files from the Hooks section ( needs ), mark the hook as trusted in /hooks, then ask Codex to create demo.js with messy spacing. The file should come out formatted. If the formatter fails, the hook shows as failed and Codex keeps working, so read the hook status instead of assuming it ran.

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

Official documentation

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

Keep going

Guidelines

AI

Agent Tools

Vibe Coding

AI in Practice

Certificate

AI Class

IT Basics

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.
Reading window