Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

:bug: Cortex being down can break harness

Open
  • Is something wrong?
#1,002 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
go
Domain
backend, cli, networking

Research direction

Start by tracing the abctl service install, stop, and uninstall behavior, including how routing through :47600 is configured. Compare the shim and soft-fail approaches in the issue before choosing a lifecycle contract. Done means a stopped Cortex does not cause harness traffic to fail, with the resulting service semantics clear for users.

Written by the indexing model from the issue text.

Description

kind/bug ux

Description

abctl service install writes proxy settings into the user's environment so any harness it was pointed at and routes through Cortex on :47600. When Cortex is down for any reason (abctl service stop, launchd killed it, abctl service uninstall didn't fully clean up), the routing stays configured but the port isn't listening. The harness's next request hits connection-refused. Cortex being down should mean "no observation," not "no traffic."

The failure mode is invisible to a user who has forgotten Cortex exists:

  • The error surfaced is generic ("network error", "cannot reach API"), not "your local proxy is down."
  • Nothing tells them their traffic is being routed through localhost.
  • Remediation (abctl service start or unsetting the routing) requires knowing Cortex exists.
  • Not scoped to a specific harness — anything abctl service install configured is affected.

Reproduction

  1. Install Cortex on a laptop where Claude Code was working, then abctl service install.
  2. Confirm Claude Code still works.
  3. abctl service stop.
  4. Send a message in Claude Code → connection error.

Potential approaches

A. Add a lightweight shim on :47600, move Cortex to :47602.
Shim always listens; forwards to Cortex when up, direct to origin when down. Harness never sees a dead port. Preserves abctl service stop as a real "kill the process" verb.

Cost: a second persistent service, one more proxy hop on every request, and more code between harness and origin — CONNECT, HTTP/2, WebSocket upgrade all get one more layer.

B. Make Cortex itself soft-fail; rename its lifecycle verbs.
Cortex process stays up as a transparent passthrough whenever its observation pipeline is down or "stopped." abctl service stop becomes "pause observation," not "kill the transport." abctl service uninstall is the only verb that removes the process and unroutes the harness. No new process, no new hop; coupling is removed by design.

Cost: a UX contract change on stop — it no longer stops the process, and existing operators have to adjust

Assisted-By: Claude (Anthropic AI) [email protected]

Dominant language
Go
Stars
13
Forks
40
Avg merge
11h 6m
Merged PRs (30d)
210

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rossoctl/cortex

All issues in rossoctl/cortex

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.