To best answer your questions, I need to cover a few areas to explain how COOKIES work and why it is useful to leverage them. This is based on my past experience with leveraging cookies in my past solutions.
COOKIES IN GENERAL
The purpose of COOKIES are to define something which gets sent in every request from the client to the server and back to the client in case those COOKIES get updated or told to clean up.
The purpose of persistent COOKIES is if the user closes the browser and re-opens it again, then the persistent COOKIES will be re-sent up in the next re-connection (stored only for that user's workstation login) so-as to resume without sending the user back to a LOGIN or SSO AUTH again because they have not yet expired.
This is beneficial because if you have a solution where you could have multiple TABS open to the SAME WEB SITE to multi-task work, you can re-use the COOKIES to resume and scale easily. Also, if the browser crashes, it can restart and resume easily to put the user back where they were last at as a convenience.
In my experience, it is common to have a SESSION COOKIE containing the SESSION ID and then the DOMAIN or SUB-DOMAIN to control security access by the page loaded by this DOMAIN or SUB-DOMAIN.
You shouldn't have to define an EXPIRATION on a SESSION COOKIE because the EXPIRATION should be set to 'Session' as the Server will know if it is expired or not.
Depending on your Web Server used, look for these type of SESSION EXPIRATION settings.
To guard against replay attacks, I've also seen AUTH COOKIES which have a SLIDING EXPIRATION. This means the EXPIRATION will SLIDE to a forward date/time of your EXPIRATION WINDOW for IDLE EXPIRATION.
IIS uses both SESSION COOKIES and AUTH COOKIES, but for whatever reason, IIS will not start SLIDING EXPIRATION on the AUTH COOKIE until it reaches 50% of the time to the initial EXPIRATION of the SESSION COOKIE. It then SLIDES EXPIRATION every request until the SERVER expires the SESSION.
SLIDING EXPIRATION FOR SESSION
Although good practice is to SLIDE EXPIRATION of the SESSION on the SERVER with every REQUEST received as you are actively communicating with the SERVER to support certain solutions where a system may need to remain up 24x7.
If concerned about persistent COOKIES, you can give the user a control to LOGOUT of the Web Site. When a LOGOUT occurs, the Web Server can request the Web Client to clear out all of it's related COOKIES.
Also, you can configure the OS to clear out the COOKIES on actual LOGOUT from their WORKSTATION.
Depending on your solution, you can adjust these rules to where if no user interaction on the CLIENT, the client can request to LOGOUT and cleanup based on your rules.
REPLAY ATTACK PROTECTION WITH AUTH COOKIES
As for protecting against a replay attack of all network traffic, the server should be validating the AUTH COOKIE VALUE to only use it once per REQUEST and changed to a new AUTH COOKIE VALUE which is has listed as available in a CATALOG maintained on the SERVER. (Multiple TABS can get tricky here so you have to decide how to deal with allowing multiple uses of the same AUTH COOKIE.)
COOKIES are protected (unlike the earlier years pre-2000) so-as to keep other web sites from jumping their gates and accessing your site's COOKIES illegally to hijack your LOGIN SESSION.
PERSISTENT COOKIES ARE SAFE TO USE
It is perfectly safe to use PERSISTENT COOKIES because you define the window of usefulness with an expiration date which should be around 15-20 minutes at most. SESSIONS on the Server should also only last at most 20 minutes before they SLIDE forward another 20 minutes after every request is received.
ANSWERING YOUR QUESTION
The SESSION COOKIE should have an EXPIRATION set to "Session". Configure the Web Server to manage the SESSION EXPIRATION for you and expire it after an IDLE TIME PERIOD passes.
The SESSION COOKIE should automatically be SENT by your CLIENT BROWSER without writing any special code.
Your WEB SERVER should manage the SESSION EXPIRATION for you, but the RESPONSE should always write the SESSION COOKIE and other COOKIES back to the CLIENT in every REQUEST to update them if they CHANGE.
With recent adoption of JWT Tokens, a JWT Token can serve both as SESSION and AUTH TOKEN as it contains an EXPIRATION and is SIGNED to protect against tampering. It also could be used to add some level of ZERO TRUST capability to your solution.
However, you have to write the code on the client and server to support it. Where-as the COOKIE use is automatic and common with most modern WEB SERVERS.