fix(codex): cap SessionEnd hook timeout at Codex's 3s limit

[z3347212573-cloud]

Problem

Fixes #381.

Codex hard-caps the SessionEnd hook timeout at 3s — the session is already exiting, so hooks are not allowed to drag on. When a hook declares a longer timeout, Codex clamps it and surfaces the clamped value as a hook loading problem in its config UI:

clamping SessionEnd hook timeout to 3s in ~/.codex/hooks.json

Memmy wrote the same HOOK_TIMEOUT_SECONDS = 60 into every lifecycle hook it installs, including SessionEnd, so the warning reappeared after every hook install/refresh — and hand-editing the timeout back to 3 was reverted by the next refresh.

Change

• codexHookEntries() now takes an explicit timeout parameter, defaulting to HOOK_TIMEOUT_SECONDS (60).
• SessionEnd passes a new SESSION_END_HOOK_TIMEOUT_SECONDS = 3.
• SessionStart, PostCompact, UserPromptSubmit and Stop keep the 60s timeout.

Both copies of the Codex target are updated, since they are byte-identical:

• App/backend/src/adapters/outbound/skill-writer/codex/target.ts
• Memory/src/agent-source/integration/codex/target.ts

Only the Codex target is touched — the 3s cap is specific to Codex's SessionEnd event.

Tests

Added caps the SessionEnd hook timeout at the Codex limit and keeps the other hooks at the default to App/backend/src/adapters/outbound/skill-writer/codex/tests/target.test.ts. It asserts SessionEnd → timeout: 3 while SessionStart and PostCompact stay at 60.

Verified locally:

• npx vitest run src/adapters/outbound/skill-writer/codex/tests/target.test.ts → 9 passed
• Reverting the source change while keeping the new test makes it fail with expected { type: 'command', …(3) } to match object { type: 'command', timeout: 3 }, so the test does cover the fix
• npm run typecheck -w @memmy/backend, npm run typecheck -w @memmy/memory, and eslint on the changed directory are all clean

[z3347212573-cloud]

Which branch should this land on?

I opened this against main, but I may have picked the wrong target: main has not received a merge since #426 (2026-09-14), while the fixes from the last few days went into release/v1.1.6, v1.1.7, computer_use and friends.

The bug from #381 is still present on the release branches as well — both App/backend/src/adapters/outbound/skill-writer/codex/target.ts and Memory/src/agent-source/integration/codex/target.ts still declare const HOOK_TIMEOUT_SECONDS = 60; on release/v1.1.6, so Codex still reports clamping SessionEnd hook timeout to 3s there.

Where would you like this to go?

• leave it on main, or
• retarget to release/v1.1.6 — I checked the ancestry first: main is an ancestor of release/v1.1.6, so the diff stays exactly the same (3 files, +45 −6), or
• v1.1.7, if that is the current bugfix line.

Happy to retarget or open a backport — just tell me which branch you prefer.

/cc @syzsunshine219 @ZongYue99

[z3347212573-cloud]

Moved this to v1.1.9.

Nobody replied to the branch question above, and v1.1.9 is clearly the active line right now: it is the only branch with commits from today, and 7 PRs have been merged into it since 9/17 (#502, #499, #496, #487, #480, #472, #466).

I rebased the commit onto v1.1.9 (applied cleanly) and retargeted, so the diff is unchanged: 3 files, +45 −6.

Tests on the v1.1.9 base: npx vitest run src/adapters/outbound/skill-writer/codex/tests/target.test.ts → 9 passed; reverting the source change while keeping the new test makes it fail with expected { type: 'command', …(3) } to match object { type: 'command', timeout: 3 }.

For reference, the bug is present on every branch I checked — main, v1.1.7, v1.1.8, v1.1.9 and release/v1.1.6 all still declare HOOK_TIMEOUT_SECONDS = 60 and pass it to SessionEnd. If you would also like a backport to a maintenance branch, say the word and I will open one.