@samooth/open-codex 0.3.11 → 0.3.13

package/README.md

@@ -24,6 +24,7 @@
 - [CLI Reference](#clireference)
 - [Memory & Project Docs](#memoryprojectdocs)
 - [Non‑interactive / CI mode](#noninteractivecimode)
+- [Editor Integration](#editor-integration)
 - [Recipes](#recipes)
 - [Installation](#installation)
 - [Configuration](#configuration)
@@ -112,6 +113,7 @@ development_ that understands and executes your repo.
 - **Multiple AI providers** — use OpenAI, Gemini, OpenRouter, Ollama, xAI, DeepSeek, or Hugging Face!
 - **High Performance** — parallel tool execution and asynchronous file indexing for speed ✨
 - **Syntax Highlighting** — full terminal color support for code diffs and file contents 🎨
+- **Security & Dependency Auditing** — built-in tools for searching npm and Snyk vulnerability databases 🛡️
 - **Full auto-approval, while safe + secure** by running network-disabled and directory-sandboxed
 - **Multimodal** — pass in screenshots or diagrams to implement features ✨
 - **Planning Visibility** — real-time display of agent `<plan>` blocks in the UI thinking state 📋
@@ -208,6 +210,21 @@ Key flags:
 
 ---
 
+## Documentation Index
+
+For more detailed information, please refer to the following documents:
+
+- **[Installation Guide](#installation)**: How to install and build from source.
+- **[Configuration Guide](#configuration)**: Customizing models, providers, and settings.
+- **[Editor Integration](#editor-integration)**: Using OpenCodex with Sublime Text and other editors.
+- **[Non-interactive / CI Mode](CI.md)**: Running OpenCodex in automated pipelines.
+- **[Recipes](RECIPES.md)**: A collection of common tasks and prompts.
+- **[Project Memory & Docs](#memoryprojectdocs)**: Managing persistent project context.
+- **[Contributing](CONTRIBUTING.md)**: Workflow and guidelines for developers.
+- **[Internal Tools](TOOLS.md)**: Details on the built-in tool architecture.
+
+---
+
 ## Memory & Project Docs
 
 Codex merges Markdown instructions in this order:
@@ -219,30 +236,6 @@ Codex merges Markdown instructions in this order:
 
 Disable with `--no-project-doc` or `CODEX_DISABLE_PROJECT_DOC=1`.
 
----
-
-## Non‑interactive / CI mode
-
-Run Codex head‑less in pipelines. Codex will automatically detect if it's running in a non-TTY environment and enable quiet mode if a prompt is provided.
-
-Prompts can be passed as command-line arguments or piped via **stdin**:
-
-```bash
-echo "explain this project" | open-codex
-```
-
-Example GitHub Action step:
-
-```yaml
-- name: Update changelog via Codex
-  run: |
-    npm install -g @samooth/open-codex
-    export OPENAI_API_KEY="${{ secrets.OPENAI_KEY }}"
-    open-codex -a auto-edit "update CHANGELOG for next release"
-```
-
-You can also explicitly enable it with the `--quiet` flag or by setting `CODEX_QUIET_MODE=1`.
-
 ## Tracing / Verbose Logging
 
 Setting the environment variable `DEBUG=true` prints full API request and response details:
@@ -255,32 +248,6 @@ DEBUG=true open-codex
 
 ## Editor Integration
 
-You can integrate OpenCodex into your favorite text editor for a seamless workflow.
-
-### External Editor (Ctrl+E)
-
-You can hit `Ctrl+E` at any time while typing in the chat to open your current prompt in your system's default editor (defined by the `$EDITOR` environment variable, like Vim, Nano, or VS Code). This is ideal for writing long instructions or pasting large blocks of code.
-
-- **Sublime Text**: Use build systems or the Terminus plugin to run Codex directly from your editor. See the [Sublime Text Integration Guide](SUBLIME.md) for details.
-
----
-
-## Recipes
-
-Below are a few bite‑size examples you can copy‑paste. Replace the text in quotes with your own task. See the [prompting guide](https://github.com/samooth/open-codex/blob/main/codex-cli/examples/prompting_guide.md) for more tips and usage patterns.
-
-| ✨  | What you type                                                                   | What happens                                                               |
-| --- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
-| 1   | `codex "Refactor the Dashboard component to React Hooks"`                       | Codex rewrites the class component, runs `npm test`, and shows the diff.   |
-| 2   | `codex "Generate SQL migrations for adding a users table"`                      | Infers your ORM, creates migration files, and runs them in a sandboxed DB. |
-| 3   | `codex "Write unit tests for utils/date.ts"`                                    | Generates tests, executes them, and iterates until they pass.              |
-| 4   | `codex "Bulk‑rename *.jpeg → *.jpg with git mv"`                                | Safely renames files and updates imports/usages.                           |
-| 5   | `codex "Explain what this regex does: ^(?=.*[A-Z]).{8,}$"`                      | Outputs a step‑by‑step human explanation.                                  |
-| 6   | `codex "Carefully review this repo, and propose 3 high impact well-scoped PRs"` | Suggests impactful PRs in the current codebase.                            |
-| 7   | `codex "Look for vulnerabilities and create a security review report"`          | Finds and explains security bugs.                                          |
-
----
-
 ## Installation
 
 <details open>
@@ -517,88 +484,9 @@ OpenAI rejected the request. Error details: Status: 400, Code: unsupported_param
 
 ---
 
-## Contributing
-
-This project is under active development and the code will likely change pretty significantly. We'll update this message once that's complete!
-
-More broadly we welcome contributions – whether you are opening your very first pull request or you're a seasoned maintainer. At the same time we care about reliability and long‑term maintainability, so the bar for merging code is intentionally **high**. The guidelines below spell out what "high‑quality" means in practice and should make the whole process transparent and friendly.
-
-### Development workflow
-
-- Create a _topic branch_ from `main` – e.g. `feat/interactive-prompt`.
-- Keep your changes focused. Multiple unrelated fixes should be opened as separate PRs.
-- Use `npm run test:watch` during development for super‑fast feedback.
-- We use **Vitest** for unit tests, **ESLint** + **Prettier** for style, and **TypeScript** for type‑checking.
-- Before pushing, run the full test/type/lint suite:
-
-  ```bash
-  npm test && npm run lint && npm run typecheck
-  ```
-
-```bash
-# Watch mode (tests rerun on change)
-npm run test:watch
-
-# Type‑check without emitting files
-npm run typecheck
-
-# Automatically fix lint + prettier issues
-npm run lint:fix
-npm run format:fix
-```
-
-### Writing high‑impact code changes
-
-1. **Start with an issue.** Open a new one or comment on an existing discussion so we can agree on the solution before code is written.
-2. **Add or update tests.** Every new feature or bug‑fix should come with test coverage that fails before your change and passes afterwards. 100 % coverage is not required, but aim for meaningful assertions.
-3. **Document behaviour.** If your change affects user‑facing behaviour, update the README, inline help (`codex --help`), or relevant example projects.
-4. **Keep commits atomic.** Each commit should compile and the tests should pass. This makes reviews and potential rollbacks easier.
-
-### Opening a pull request
-
-- Fill in the PR template (or include similar information) – **What? Why? How?**
-- Run **all** checks locally (`npm test && npm run lint && npm run typecheck`). CI failures that could have been caught locally slow down the process.
-- Make sure your branch is up‑to‑date with `main` and that you have resolved merge conflicts.
-- Mark the PR as **Ready for review** only when you believe it is in a merge‑able state.
-
-### Review process
-
-1. One maintainer will be assigned as a primary reviewer.
-2. We may ask for changes – please do not take this personally. We value the work, we just also value consistency and long‑term maintainability.
-3. When there is consensus that the PR meets the bar, a maintainer will squash‑and‑merge.
-
-### Community values
-
-- **Be kind and inclusive.** Treat others with respect; we follow the [Contributor Covenant](https://www.contributor-covenant.org/).
-- **Assume good intent.** Written communication is hard – err on the side of generosity.
-- **Teach & learn.** If you spot something confusing, open an issue or PR with improvements.
-
-### Getting help
-
-If you run into problems setting up the project, would like feedback on an idea, or just want to say _hi_ – please open a Discussion or jump into the relevant issue. We are happy to help.
-
-Together we can make Codex CLI an incredible tool. **Happy hacking!** :rocket:
-
-### Releasing `codex`
-
-To publish a new version of the CLI, run the release scripts defined in `codex-cli/package.json`:
-
-1. Open the `codex-cli` directory
-2. Make sure you're on a branch like `git checkout -b bump-version`
-3. Bump the version and `CLI_VERSION` to current datetime: `npm run release:version`
-4. Commit the version bump (with DCO sign-off):
-   ```bash
-   git add codex-cli/src/utils/session.ts codex-cli/package.json
-   git commit -s -m "chore(release): codex-cli v$(node -p \"require('./codex-cli/package.json').version\")"
-   ```
-5. Copy README, build, and publish to npm: `npm run release`
-6. Push to branch: `git push origin HEAD`
-
----
-
 ## Security & Responsible AI
 
-Have you discovered a vulnerability or have concerns about model output? Please e‑mail **security@openai.com** and we will respond promptly.
+Have you discovered a vulnerability or have concerns about model output? Please **open a GitHub issue** or submit a pull request with a fix. We take security seriously and will respond promptly.
 
 ---