CoderLuii/HolyClaude

HI
Small follow-up after testing this in a real HolyClaude setup:

`Codex CLI` and `Codex chat` are actually two different cases.

What I found:
- `Codex CLI` can use `~/.codex/hooks.json`
- but `Codex chat` inside HolyClaude does **not** seem to go through those CLI hooks
- instead, it appears to use HolyClaude’s internal notification flow/server-side provider integration

So from a user perspective, the request is broader than just “support Codex CLI notifications”:

Expected behavior:
- notifications should work for:
- Claude chat
- Claude Code
- Codex chat
- Codex CLI
- ideally the other bundled providers too
- notifications should be sent on:
- task completion
- task failure
- permission notifications are not needed in my case

Why this matters:
A lot of long-running work now happens in the HolyClaude chat providers, not only in the raw CLIs. If notifications only exist for CLI hooks, the “start task and walk away” workflow is st...

Hi
No it’s not fixed on my end. Tried with a private session too just in case.
Also, there is a cloudcli update request, I don’t now if we need to do it ?
Thanks

Closing as fixed in v1.1.9.

Thanks. This one was real.

The important part was that the Codex session was not actually getting lost. It got created, the first prompt went through, and then the UI kicked you back to the new session page. That pointed at session completion and navigation handling, not session creation.

I checked the CloudCLI side and the completion path really was treating successful completion too narrowly.

This is fixed in [`v1.1.9`](https://github.com/CoderLuii/HolyClaude/releases/tag/v1.1.9).

What changed:

Successful completion no longer depends on an explicit `exitCode === 0` just to finalize the pending session view.

That keeps the UI on the active Codex session after the first prompt instead of bouncing back to `new session`.

Short version: the session existed before, and now the UI should stop mishandling completion.

If you still hit this on `v1.1.9`, reply here and I’ll reopen it.

Hi
Would it be possible to get a notification when permissions are asked ?
Thanks !

Hey @CoderLuii, thanks for adding Codex/Gemini notification support in v1.1.7!
For anyone finding that Codex notifications still don't fire after upgrading: the bootstrap only runs once, so if your container predates v1.1.7, the new Codex configuration was never written.
You can confirm this is your situation by checking ~/.codex/config.toml — if it doesn't contain [features] with codex_hooks = true, and there's no ~/.codex/hooks.json, your bootstrap ran before the Codex hook setup was added.
Two ways to fix it:
Option 1 — Re-run bootstrap (cleanest, but resets settings.json and CLAUDE.md to defaults):
`rm ~/.claude/.holyclaude-bootstrapped
# then restart the container
`
# then restart the container
Option 2 — Manually create the missing files (surgical, preserves your existing config):
Update ~/.codex/config.toml to add:
`toml
Copy
[
features
]
codex_hooks = true
`And create `~/.codex/hooks.json`:`json
{
"hooks": {
"Stop": [
{
"hooks": [
{
"ty...

Shipped in [`v1.1.7`](https://github.com/CoderLuii/HolyClaude/releases/tag/v1.1.7).

Codex and Gemini CLIs now have Apprise notification hooks pre-configured. Same `notify-on` flag file, same `NOTIFY_*` env vars, works exactly like Claude Code notifications. No extra setup needed.

Cursor CLI hook is pre-configured but the `stop` event doesn't work in Cursor CLI yet (only in the IDE). It will activate automatically when Cursor adds support.

Junie, OpenCode, and TaskMaster don't have hook systems so notifications aren't possible for those yet.

Also in this release: Codex CLI is now pre-configured with `on-request` approval (no more 9x "approve node" prompts), and all CLI configs/auth persist across container rebuilds.

haha claude writing its own bug reports, love it. glad its working well on your phone too, thats exactly the use case i had in mind. no laptop, just a browser and your server doing the work.

just got your 5 euros, seriously appreciate it. youre the first supporter ever. actually just finished setting up the membership tiers on buymeacoffee because of you lol.

the bubblewrap fix is done and tested locally. waiting for the build to finish and ill tag v1.1.6. ill reply here once its live so you can pull the latest.

I have found your buymeacoffee on your site.
Also you should update it as codex works with a chatgpt plus subscription
Finally, as I don’t know what I am talking about as a non coder, there are a bunch of tools to be allowed in the permissions settings of Claude but there are not in the codex permissions. Is it a limitation or could they be implemented ? It asked me 9 times to proceed with node, it was cumbersome to select yes each time on the phone
Many thanks

haha claude writes better bug reports than most humans honestly. appreciate the kind words!

yeah i do have a buy me a coffee: https://buymeacoffee.com/CoderLuii

glad its working well for you on mobile, thats exactly the use case i built it for. no laptop needed, just a browser and a server doing the work.

You are welcome, this is Claude who did the heavy lifting of writing the issue 😂
Awesome project !
Do you have a buymeacoffee or what ?
I am currently on the phone messing with Claude code and codex, no more need of a laptop !

thanks for the detailed report. this is a clear issue with bubblewrap needing user namespaces that synology kernels restrict.

the fix is straightforward, adding `bubblewrap` to the image and setting the setuid bit so it works without user namespace support:

```dockerfile
RUN apt-get install -y bubblewrap && chmod u+s /usr/bin/bwrap
```

this will land in the next release. on standard linux hosts bwrap still uses namespaces normally so no behavior change there, the setuid bit only kicks in on restricted kernels like synology.

appreciate you including the suggested fix, saved me the research time.